Why does AUTHORITY-CHECK give different result than function module AUTHORITY_CHECK?

[BaerbelWinkler]

We sometimes use an AUTHORITY-CHECK against S_DEVELOP with ACTIVITY '03' (or '02') to control if fields on a selection-screen should be open for input or not:

* Only developers can change max number of items to select
  AUTHORITY-CHECK OBJECT 'S_DEVELOP'
           ID 'DEVCLASS' DUMMY
           ID 'OBJTYPE'  DUMMY
           ID 'OBJNAME'  DUMMY
           ID 'P_GROUP'  DUMMY
           ID 'ACTVT' FIELD '03'.

  IF sy-subrc NE 0.
    LOOP AT SCREEN INTO DATA(ls_screen).
      IF ls_screen-group1 EQ 'DEV'.
        ls_screen-input = '0'.
        MODIFY SCREEN FROM ls_screen.
      ENDIF.
    ENDLOOP.
  ENDIF.

Now we happened upon a case during testing, where a user who is not a developer passes this check with SY-SUBRC = 0 and we don't understand why that is the case as we don't see a developer-related role in his profile. If we check the user via SE37 and function module AUTHORITY_CHECK and the corresponding values for ID and FIELD we get the expected error USER_NOT_AUTHORIZED back:

Shouldn't the actual authority check in the program and the function module produce the same result? I find it a bit "disconcerting" that they don't, to tell the truth! Or are we missing something? And yes, I noticed that the FM is "not released".

I tried finding something about this but it's kind of difficult with the many hits found when searching for "Authority-check"!

We are on NW750 EHP8

Thanks much and Cheers

Bärbel

[FredericGirod]

I am happy to not having your problem! 🙂

Did you try to put a ST01 trace, and check you are loocking the right code ?

[BaerbelWinkler]

frdric.girod

LOL, Fred!

Haven't tried ST01 trace yet as - IIRC - we don't have authorization to run the auth-trace. We however looked at it via debugging, so I'd hazard the guess, that we are in the correct program. I think that the authority-check in the ABAP-code actually triggers a kernel function and that the FM is therefore a completely different entity. I'm just suprised that they don't give the same result regardless.

[RaymondGiuseppi]

Which transaction was executed by the user, some transactions (and other objects) can be defined to override authority-check, call SU24 for the transaction, and look at column 'Check Indicator', is some authorization object tagged as 'Do not check'? (NB: The profile parameter AUTH/NO_CHECK_IN_SOME_CASES activate this behavior, check with RZ10 or ask basis)

If ST01 is not allowed, did you also check with SU53 (or SU56 for buffer analyzsi) for an unexpected successful check?

[BaerbelWinkler]

raymond.giuseppi

Thanks for the pointers, Raymond! TCodes SU24 and SU56 seem to be worth adding to my list of favorites!

Thing is, that in the meantime, the program was changed to query for ACTIVITY = '01' instead of '03' and it now throws the expected error when the user tries to execute it in the test system. We therefore can no longer test it under the same conditions as yesterday. The transaction is just a simple Z-Tcode without any special authorizations as we query the relevant ones within our programs (which in this particular case is for displaying material + plant data via M_MATE_WRK). SU24 therefore doesn't show anything for the TCode.

Cheers

Bärbel

[RaymondGiuseppi]

Developers rarely enter SU24 for specific transactions. This is a pity because the information entered there in addition to a document role is used by PFCG when creating the roles.

[FredericGirod]

Does your authority check is in an event of the program ? maybe the user find a way to not go in this event before executing the program ...

[BaerbelWinkler]

frdric.girod

It's done in AT SELECTION-SCREEN OUTPUT and other logic in that event is processed so the auth-check should be as well. But, as mentioned below in my response to Raymond, we can no longer test as the code was changed in the meantime.

[Sandra_Rossi]

TL;DR

DUMMY of AUTHORITY-CHECK (ABAP statement) = no mention of authorization field in AUTHORITY_CHECK (function module).

LONG version

In 7.52, if parameter USER is not passed (or set to SY-UNAME), the code of function module AUTHORITY_CHECK is strictly equal to:

  authority-check object object
          id field1  field value1
          id field2  field value2
          id field3  field value3
          id field4  field value4
          id field5  field value5
          id field6  field value6
          id field7  field value7
          id field8  field value8
          id field9  field value9
          id field10 field value10.

So, you can assume that there can't be any difference with AUTHORITY-CHECK.

The main difference in your code is around DUMMY. If you call AUTHORITY_CHECK with parameters set to 'DUMMY', it's equivalent to:

AUTHORITY-CHECK OBJECT 'S_DEVELOP'
           ID 'DEVCLASS' FIELD 'DUMMY'
           ID 'OBJTYPE'  FIELD 'DUMMY'
           ID 'OBJNAME'  FIELD 'DUMMY'
           ID 'P_GROUP'  FIELD 'DUMMY'
           ID 'ACTVT'    FIELD '03'.

which means that there must be at least one authorization with field DEVCLASS matching 'DUMMY' and field OBJTYPE matching 'DUMMY', etc.

That's not equivalent at all to your requirement:

  AUTHORITY-CHECK OBJECT 'S_DEVELOP'
           ID 'DEVCLASS' DUMMY
           ID 'OBJTYPE'  DUMMY
           ID 'OBJNAME'  DUMMY
           ID 'P_GROUP'  DUMMY
           ID 'ACTVT'    FIELD '03'.

which is strictly equivalent to:

  AUTHORITY-CHECK OBJECT 'S_DEVELOP'
           ID 'ACTVT' FIELD '03'.

Or even, less intuitively (and less officially as it's not in the ABAP documentation but it can be deduced from the SAP note 1022413 - Make AUTHORITY-CHECK and AUTHORITY_CHECK consistent, "The same result can be achieved when calling function module AUTHORITY_CHECK", and from AUTHORITY_CHECK code), to:

  AUTHORITY-CHECK OBJECT 'S_DEVELOP'
           ID ''      FIELD ''
           ID ''      FIELD ''
           ID ''      FIELD ''
           ID ''      FIELD ''
           ID 'ACTVT' FIELD '03'.

And so, your requirement is strictly equivalent to:

CALL FUNCTION 'AUTHORITY_CHECK'
  EXPORTING
    object   = 'S_DEVELOP'
    field1   = 'ACTVT'
    value1   = '03'.

or

CALL FUNCTION 'AUTHORITY_CHECK'
  EXPORTING
    object   = 'S_DEVELOP'
    field5   = 'ACTVT'
    value5   = '03'.

or even:

CALL FUNCTION 'AUTHORITY_CHECK'
  EXPORTING
    object   = 'S_DEVELOP'
    field1   = ''
    value1   = ''
    field2   = ''
    value2   = ''
    field3   = ''
    value3   = ''
    field4   = ''
    value4   = ''
    field5   = 'ACTVT'
    value5   = '03'.

NB: the next one is wrong because it looks for an authorization with fields containing a real space value (' '):

  AUTHORITY-CHECK OBJECT 'S_DEVELOP'
           ID 'DEVCLASS' FIELD ''
           ID 'OBJTYPE'  FIELD ''
           ID 'OBJNAME'  FIELD ''
           ID 'P_GROUP'  FIELD ''
           ID 'ACTVT'    FIELD '03'.

[BaerbelWinkler]

sandra.rossi

Thanks for your detailed explanation, Sandra! I'm sure it'll help not just me but also others puzzled by the subtle difference!

So, when the check for the user came back with "no authorization" in the function module version of the check the reason was that it failed for him not having authorization for the fields checked against "DUMMY" and not because of the activity as we thought (or wrongly jumped to the conclusion!).

Cheers

Bärbel