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: 

Authorization issue even if user has the correct role

sanjana_lingras
Active Participant
0 Kudos

Hi Team,

We are facing one strange issue. User faces authorization error, after checking the roles user has all the relevant roles.

Now when user changes the date format to MM/DD/YYYY in his profile then he is able to execute the t-code.

We are not able to resolve this issue, everytime to resolve this Authorization error user has to change date format in his profile.

Is there any way to resolve this auth error?

Thanks.

regards,

Sanjana

20 REPLIES 20

Colleen
Advisor
Advisor
0 Kudos

Hi Sanjana

What transaction code is the user executing? Is it a custom transaction? What error message does the user receive?

Regards

Colleen

former_member314331
Participant
0 Kudos

may I know which Transaction having this issue  ??

is this issue for all users ? did you try same thing in other system with same user ?

Regards,

Phani

0 Kudos

Hi,

This is happening for custom transaction.We took ST01 trace it returns RC=4.

We feel that this issue is with user profile setup.

When user changes date format in his profile, he is able to execute the t-code and authorization error is not coming.

I just RC4 means "No profile contained in user buffer" but I not getting how can we fix this issue.

The role which I am getting from SUIM is already assigned to user.

Regards,

Sanjana

0 Kudos

Hi Sajana

If you are saying user the user changing their date format means the RC=4 becomes RC=0 on an authorisation check AND it is a custom transaction then you need to send this to your ABAP developer and have them fix their code.

It may appear in your trace as a security authorisation issue but the root cause is the code.

Regards

Colleen

0 Kudos

hi colleen , this is not related to code few users are facing this issue and few are not.

So this is definitely it's not related to code.

Regards,

Sanjana

0 Kudos

It is either code or pixi dust, or Obama again...

0 Kudos

Sanjana ,

have tried with reset user buffer ?

Regards,

Phani

0 Kudos

Are you making an assumption that it can't be the code or did you have the developer check the code?

0 Kudos

What about the other users who are executing the t-code?

Are they changing the date format?

Is this happening for this user only recently?

Was the t-code working for the user before without changing the date format?

Regards

Deepak M

0 Kudos

Hi Collen,

In ABAP program, there is authority check for report execution authorization object. If sy-subrc is 4 then error is thrown. This authorization object is already present in the role assigned to user with the same report program name.

But still user faces auth issue.

Regards,

Sanjana

0 Kudos

Hi Sanjana

Again, did you make the assumption or did you take your analysis to a developer? I have no idea who "we" is in your replies.

Let's break it down

  1. It is a custom transaction code so I am assuming it is a custom program
  2. User has required authorisations
  3. User has DATE FORMAT DD.MM.YYYY (or whatever)
  4. User is not authorised (RC=4) in the trace file
  5. User now has DATE FORMAT MM/DD/YYYY
  6. User still has same authorisations and executes same transaction
  7. User is now authorised (RC=0)

That is how you have explained it to us. In your explanation you have never said the user's authorisations changes - just their timezone.

The reason I conclude coding and why Julius mentions the pixies (and we're talking gremlins and not an awesome band) is that the program logic is askew.

Program Logic seems to be (not necessarily this simplistic) in following pseudo-code format.

If DATE FORMAT = "MM/DD/YYYY" Then

     XXXXXXX

      AUTHORITY-CHECK OBJECTX

     RC = 0 as the outcome --> it works

Else

     YYYYY

     AUTHORITY-CHECK OBJECTX (or another object?)

     RC = 4 as the outcome --> it does not work

End If

The possibilities could be:

  • Different code is being executed based on the authority check (possibly even a different authorisation)
  • The return code for the authority check is being handled differently (unlikely if you claim RC 0 in one scenario and RC 4 in another for the same user with the same roles).
  • The authorisation check is for different permissions (for some reason the program is restricting based on timezone - not sure why?!?)

My recommendation

  1. Take screen shot of SU56 user buffer for the user in question
  2. Set time zone for scenario where it works and trace STAUTHTRACE and ST01 showing the execution - see the results
  3. Set time zone for the scenario where it fails and repeat the trace
  4. Send analysis to the developer and tell them to fix their code (or at least debug the code and prove to you that it is security)

If not, go back through your assumptions and check what your analysis is to see if you missed something. Regardless, stop make general claims (few users facing it and few users not). Instead deal with specifics - which users? which transaction? which program? which authorisation? Do all users have that authorisation in their user buffer (SU56) to rule out profile corruption. For the users with the issue, do they have the same DATE FORMAT? For the users receiving the error do they have the DATE FORMAT MM/DD/YYYY (the one that is meant to work).

End of the day, you need to analyse this and break down the logic.

Regards

Colleen

0 Kudos

@Colleen,

Thanks a lot for the post...Just learning how to break down a issue to arrive at a solution.....

@sanjana,

Please check the time zone of the system.

Regards

Deepak M

0 Kudos

Sanjana Lingras wrote:

Hi Collen,

In ABAP program, there is authority check for report execution authorization object. If sy-subrc is 4 then error is thrown. This authorization object is already present in the role assigned to user with the same report program name.

But still user faces auth issue.

Regards,

Sanjana

Ha! There is no standard object for that. So custom object in custom code.

IF sy-subrc = 4 is not enough. It can also be 12, or other values even.

Only IF sy-subrc = 0 is success and I wager a bet the timezone is a field of the object in addition to program name.

Or not reacting to sy-subrc after check and then assuming time zone is always fine and then rsising an error.

Definately Obama who made you write this code! Please post your code...

Cheers,

Julius

0 Kudos

Good idea to ask for the code...looking at Sanjana's activity in SCN - Sanjana might be the developer.

0 Kudos

Are you going to post your code, or not?

0 Kudos

One possible insane scenario would be having a date as a field on the auth object. If that were in the wrong format, that'd explain it.

Of course, given this apparent stubborn refusal to be helped by posting the actual code, it seems we'll never know.

Former Member
0 Kudos

dear all

please check user and system time zone and i one suggion is if a user not face a problem copy from this use to new user and chek,

nainesh

Former Member
0 Kudos

Hi

As well as the code... 🙂 (not the auths)

Standard transactions can behave in a similar fashion for , and . for currencies and the preceding documents created by a user with a , rather than a . in the amount field can cause the following users issue when processing subsequent documents.

Have all of the documents being processed by this custom transdaction been created in the same format or has each previous person been using differing personal settings?

If they are in a global environment then the code needs clarifying otherwise the user will have to keep swapping from DD/MM to MM/DD and back again every time they use the transaction.

Best wishes

David

sanjana_lingras
Active Participant
0 Kudos

Hi All,

I checked SU56 for that particular user and found auth object is added but error is r “Available in master data ,but not in the user buffer”. May be this causing the issue.

Regards,

Sanjana

0 Kudos

Hi Sanjana

If that is the case, then PFUD/user compare will resolve for you. It also means that you did not describe your scenario accurately as that suggests you made changes to the user access (and possibly change of date format was a coincidence).

If fixing the SU56 error does not resolve your error, you will unlikely get much more assistance from this space without posting an extract of your code. Otherwise, it's a guess game - particularly when it is custom development.

Regards

Colleen