Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

BAPI authorization check

rt50896
Participant
0 Kudos

dear all,

i have a situation: when execute BAPI FM in R/3,is there any way to restrict any transaction post?

ex. FM BAPI_INCOMINGINVOICE_CREATE' use to post LIV document by SE37 directly,it's a risk

that no auth.check in this FM...if need,which auth.object can use to avoid this ?

regina

1 ACCEPTED SOLUTION

rt50896
Participant
0 Kudos

Hi Julius,

Thanks for your re-allocate & reply ~ it's very clear to fit my question,i know this should not post by FM test,i concern it because try to prevent anyone which have auth. to post document by BAPI by SE37 directly - so for auth. restriction in SE37,is this possible that for BAPI FM in SE37 only display and can't be execute? i ever test for SE37 auth. in PFCG as follow by auth object S_DEVELOP:

ACTVT: 03 (display)

DEVCLASS : *

OBJNAME : A~X (only standard function group,except add-on)

OBJTYPE : FUGR,FUGC

P_GROUP : *

but BAPI FM still can be execute,not display only...

regina

10 REPLIES 10

Former Member
0 Kudos

This message was moderated.

Former Member
0 Kudos

This message was moderated.

Former Member
0 Kudos

This message was moderated.

Former Member
0 Kudos

Hi

But why should u post a document by SE37?

U should call the BAPI in a your program or in a external program where the authorizations should be checked before calling the BAPI

Former Member
0 Kudos

Moved from ABAP General to Security forum...

I agree with Max. A process design where the business entry point is the ABAP workbench (SE37, SE80, etc) is not a good idea. See SAP Note # 587410 to prevent it.

A BAPI (in a function group) should fullfill the functional requirements of its corresponding transaction group, but by definition without the transaction code check...

When you have the users off the workbench, then you need to write a program to call the BAPI. You can take care of security requirements in your program as well if the BAPI interface does not achieve your requirements, or write your own BAPI wrapper to call the SAP BAPI.

What you should also be aware of is that BAPIs will conform to the transactional consistency of the data which they are processing. So when single testing a BAPI FM with incomplete or incompatable entry data, you need not be surprised when no checks are performed, because no posting will happen either...

Take a look in the RETURNS table to see what came back?

You can test this in SE37 by using the "add sequence" function (it is in the menu somewhere...) and call BAPI_TRANSACTION_COMMIT.

If the transaction goes through and the user context for the authority-checks should not have the authority to post it... then you need to check this in your application coding (acting as the RFC client) before calling the BAPI. If the BAPI is being used with the destination parameter, those checks will be performed against the user ID entered in the RFC destination data. You won't see that in your own local trace... nor influence it by restricting your own authority.

Cheers,

Julius

rt50896
Participant
0 Kudos

Hi Julius,

Thanks for your re-allocate & reply ~ it's very clear to fit my question,i know this should not post by FM test,i concern it because try to prevent anyone which have auth. to post document by BAPI by SE37 directly - so for auth. restriction in SE37,is this possible that for BAPI FM in SE37 only display and can't be execute? i ever test for SE37 auth. in PFCG as follow by auth object S_DEVELOP:

ACTVT: 03 (display)

DEVCLASS : *

OBJNAME : A~X (only standard function group,except add-on)

OBJTYPE : FUGR,FUGC

P_GROUP : *

but BAPI FM still can be execute,not display only...

regina

0 Kudos

A simple answer to your concern would be that no one should have that authorization in production.

At a previous assignment we clearly minimized the authorizations for the developers in the production system. It was not easy to change things that were "in the walls" of the organisation.

In my humble opinion, no one should have the possibility to use system development functions in a production system. It is intended to be used by end users!

Only when something is not possible to reproduce in the test environment, sufficient authorizations can be temporarily assigned to a developer in production, and soon after the issue is solved be removed again.

Regards Fredrik

Former Member
0 Kudos

In addition to Fredrik's good advise, please take note that you are talking about 2 different types of authority-checks now.

Previously, we were discussing checks performed by the BAPI itself (for example F_BKPF_BUK and F_BKPF_KOA etc).

What you are now refering to are the S_DEVELOP checks performed within the development workbench when generating the test environment for the function module. These are performed before the BAPI's own checks are.

That the system is checking activity '03' when executing the function module, is because you are most likely on a 46C SAP system.

I strongly recommend that you implement SAP Note # 587410 (can be done easily via SNOTE) to differentiate between displaying such development objects, and executing them directly from the workbench tools...

Cheers,

Julius

Former Member
0 Kudos

Hi,

Is there a BAPI version of AUTHORITY_CHECK_TCODE? I have written an application which calls BAPI_ACC_GL_POSTING_POST but this permits posting even if user has no authorization to the trasnaction, or to post to the underlying company code.

Thanks.

Former Member
0 Kudos

What you can do is create a webservice for the BAPI (you might not even need to "write" the application as you can also simply "compose" it...) and then use object S_SERVICE to protect the entry point.

S_SERVICE is basically the same as S_TCODE as it controls the "start it" request and not the "use it" result.

Another option to use is object S_ICF if your application is an ABAP SAPGui transaction - this protects the destination from being called if you configure the system to do so.....

Cheers,

Julius