0

I was trying to implement an authority-check in my DPC_EXT class of an OData service for the entity todos in the get_entity method:

  METHOD todosset_get_entity.

    AUTHORITY-CHECK OBJECT 'S_TABU_NAM'
    ID 'ACTVT' FIELD '03'
    ID 'TABLE' FIELD 'ZALM_FS_TODOS'.

    IF sy-subrc <> 0.
      MESSAGE |No Authorization access! | TYPE 'E'.
*     Implement a suitable exception handling here
    ENDIF.

In the first try, it did not work, which was expected. Then I added the rights for my user in PFCG: enter image description here

I then generated the profile and added my user, and it worked as expected.

BUT:

I then removed my user from the role completely... (and also inactivated and regenerated the profile), but it still did work to retrieve single todos in my gateway service.

I don't understand why, do I have to regenerate the classes in SEGW? Clear caches or something?

Did I overlook something?

And by the way, it made no difference if the TABLE authorization field value was changed to ZALM_FS_TODOS or ZALM_FS_USERS, but I don't get it why, it did not work in the first place... and after adding my user to the generated correct security profile it did work... so it should be the other way around and not work anymore when I revert my security roles again!?

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
MMMM
  • 3,320
  • 8
  • 43
  • 80
  • 1
    From what you describe, I think that the issue is more related to the authorization data only. Either you have a Central User Administration and it takes time to replicate your changes or the data is buffered or you have several application servers. It would be better if you activate the authorization trace and repeat your tests (`STAUTHTRACE`). – Sandra Rossi May 12 '23 at 18:24
  • tray a break-point on the statement "AUTHORITY-CHECK" in debugger, or run an authorization trace using ST01 with a filter on your user. – phil soady May 12 '23 at 20:40
  • The STAUTHTRACE wasn't very useful... it showed everything green and I still could not get the reason why.. it seemed in the debugger class that it did not check the auth object fields for the correct values for whatever reason... – MMMM May 15 '23 at 08:30

1 Answers1

0

Hmm, I could not get an answer to this except maybe the fact that those same authorization objects are assigned by another role, e.g "SAP_ALL", and maybe the checked fields are '*' or 'DUMMY' and it gets bypassed every time by the auth checks for the default roles... (but I'm new to this and not sure if it behaves like that).

So I think the correct solution was to create your own Auth object class and auth object in su21 according to http://saphelp.ucc.ovgu.de/NW750/EN/4c/a0ac7a68243b9ee10000000a42189b/frameset.htm and if you need, you can also create your own auth fields. I did this in my namespace Z*... Then I could select my own auth objects manually in pfcg role and enter whatever I wanted and the auth-check on program level worked nicely as expected :) enter image description here

MMMM
  • 3,320
  • 8
  • 43
  • 80