AUTHORITY-CHECK Basics

[Former Member]

Hey There,

I am a new ABAPer and I have been asked by my manager to implement an AUTHORITY-CHECK on a few of our apps. I was wondering could any of you give me a bit of a kick-start with regards to how I should go about this.

I am supposed to add the following check:

AUTHORITY-CHECK OBJECT 'S_TCODE'

ID 'TCD'

FIELD 'XXX'

Where XXX is the field that I am supposed to check against.

I have already implemented Authority checks that checked whether the user had rights to view the data held in a table in the DB but I am not sure where to place this Authority check and how to Identify the field which I want to check.

If anyone could help me I would be very grateful.

Cheers

[Former Member]

Hey There,

I am a new ABAPer and I have been asked by my manager to implement an AUTHORITY-CHECK on a few of our apps. I was wondering could any of you give me a bit of a kick-start with regards to how I should go about this.

I am supposed to add the following check:

AUTHORITY-CHECK OBJECT 'S_TCODE'

ID 'TCD'

FIELD 'XXX'

Where XXX is the field that I am supposed to check against.

I have already implemented Authority checks that checked whether the user had rights to view the data held in a table in the DB but I am not sure where to place this Authority check and how to Identify the field which I want to check.

If anyone could help me I would be very grateful.

Cheers

[Former Member]

Hi,

Take a read through AUTHORITY_CHECK_TCODE for your options.

Cheers,

Julius

[Former Member]

Thanks Julius,

But I am kind of looking for a more specifc answer. We have an app that already has one of these checks in place. It goes as follows:

AUTHORITY-CHECK OBJECT 'S_TCODE'

ID 'TCD'

FIELD 'ME33K'.

Therfore my specific question would be how did this programmer know that ME33K was the field he needed to check. I can find nothing in the code that suggests why ME33K was used but I hope that if I follow the same steps I can determine the fields for the apps that I need to do.

Thanks again,

Colm

[morten_nielsen]

Hi Colm

The ME33K, is the sap transactioncode that's called. When you call your own developed SAP functionality, this should also be done through the call of a transactioncode.

But please notice that the AUTHORITY-CHECK OBJECT 'S_TCODE', only is one of the checks, and that this check <b>always</b> is performed when you call a transaction code, it doesn't need to be implemented in your source code.

If you need a more detailed check, you can take a look in SU21, within this transaction you will also be able to access the documentation for standard authorization objects, or even to create your own object.

When you the implement the authorization check in your source, use the <i>pattern</i> button, and you'll get the fields defaulted in.

Regards

Morten Nielsen

[Wolfgang_Janzen]

Well, if you have a report transaction then it might be advisable to place a call to function module AUTHORITY_CHECK_TCODE at the beginning (AT INITIALIZATION) of the underlying report source code - since it is possible to start the report directly (via SA38 or Easy Access Menu).

That's what Julius was indicating (with less words than me).

Cheers, Wolfgang

[Former Member]

It also means that you can use more control possibilities BEFORE you call the transaction.

Cheers,

Julius

[Former Member]

Before your thread gets highjacked...

>> Therfore my specific question would be how did this programmer know

>> that ME33K was the field he needed to check. I can find nothing in the

>> code that suggests why ME33K was used.

A possible solution would be to find the Business Requirements (document?) for the report having been developed in the first place, or some Technical Specs on it, to see whether the developer got the requirement from there?

Some possibilities:

If the developer put this check in his ABAP and reacts to sy-subrc <> 0, then the requirements might specifiy: <i>"Only users who can START (not necessarily use!) transaction ME33K should also be allowed to run this report and then select the "Go to Contracts Overview" button."</i>

If the developer didn't react to the authority-check statement, then the requirements might specify:<i>"Any user running the report without having authorization for transaction ME33K, should be unhindered by this fact. However, if they run a /nSU53 afterwards (but before failing any other authority-check) then they should be informed that the missing authorization is transaction ME33K."</i>

Cheers,

Julius

[Former Member]

Thanks Julius,

You seem to have grasped the guts of the problem. I was talking to the developer who added that authority-check and that was exactly the situation. He was given the requirements to add in the check. This unfortunatly still doesn't solve my problem. As <b>it still doesn't give me a step-by-step process that I can follow to add in the authority-check for the 100+ apps I have to do</b>.

I am not sure if there IS a step-by-step process that I can follow but when my mentor was showing me what he wanted me to do he seemed to have a process that he was following. Unfortunatly he is now out sick and I was hoping to have this task completed when he returned but as it stands i am making no progress at all.

Thanks again for your help though,

Much appreciated,

Colm

[Former Member]

What do you mean by "<b>the</b> authority-check"? Are they all against ME33K and you now want to change it to something else? -> very unlikely.

The step-by-step way of doing it is to get yourself the various business requirements for the 100+ apps (BTW what is meant by an "app"?), translate them into a concept using authorization objects and code them in the 100+ apps... also step-by-step. This would also be helpfull for any future developer who has to maintain these apps.

At this point you could (possibly) think of using the modularization concept (e.g. function calls) to save yourself some time in having to code the same or similar ABAP text into all these apps. You could even put the values to be checked into a table for given system fields found by the function module (e.g. sy-repid, or sy-tcode...), optionally with flags for "On" and "Off"... However you must secure this table of course because table maintenance = authorization maintenance in this case!

As mentioned before (but in much less words ), take a look at AUTHORITY_CHECK_TCODE for some ideas or options.

Cheers,

Julius

PS: Do you know the joke about the two developers who walk into a development project?

[Former Member]

OK So my manager showed me what he wanted me to do. Basically if there is a CALL TRANSACTION in the code the transaction code will immediatly follow that:

i.e. CALL TRANSACTION 'XXXX'

therefore when I am implementing my authority check i should do it as follows:

AUTHORITY-CHECK OBJECT 'S_TCODE'

ID 'TCD'

FIELD 'XXXX'.

Thats what I have to do anyway. Dunno if it is an industry standard but thats what I'm at.

Cheers for the help anyway.

Never heard the joke? What is it?