Using Authority-check statement in WDA Application

[Former Member]

Hi Experts,

I have a doubt regarding the use of the Authority-check statement in a WDA develeopment.

In my scenario i have some views which needed to be displayed only to some users who are the administrators and some who are the normal users. In order to achieve this I was using the Authority-check statement and it was done sucesfully in one server. here i have created two Z authorization objects and authoirization value field and created a new authorization class.

we also have seperate roles created for ADMIN and USER module. Now in my main view, in the DOINIT, statement i was using the Authority-check statement and based on the sy-subrc which is retured, i was navigating to the corresponding views.

This approach was working fine in my servers. when i imported all these developements into another server, the Authority-check statement is returning the value of sy-subrc as zero always, irrespective of whether the user has the role assigned to him or not.

what can be the reason for this behavior in the new server, and is there any way i can make the server to execute the authority-check statement and return the sy-subrc correctly?

thanks in advance for your suggestions.

Ajith

[Former Member]

"The authority check is carried out if the check indicator for the specified authorization object for the current context is set to check with any proposal status. If the check indicator is set to no check, no authority check is carried out and sy-subrc is set to 0, as with a successful check."

This is what i found in the F1 help. This might help.

[thomas_jung]

This doesn't really sound directly related to WDA. Authority checks are long standing procedures to perform the kind of logic you describe. They work in classic dynpro as well as WDA the same. There should be no different with the authority-check simply because it is running in WDA. I supose the main thing to check is that in this other server that the user is really running as themselves. Make sure you don't have a user embedded in the service definition or something strange with user mapping if this is running in the portal. Otherwise this should be normal authority check debugging - run a security trace to see why the authority check is passing.

[Former Member]

Hi Thomas Jung,

Thanks for your quick reply. Yes i was also using the Authority-check statement to validate the user authorization because of the same reason and as i mentioned it was working fine in our server. The problem happens only in the new server and since i am testing it directly using the url, and not from the portal, there is no real problems with any user configuration issues.

The only major difference between the first server and the second server is that in the first server the application was running with an HTTP url and in the second server it is running with an HTTPS url.Whether this is going to have such an impact in case of the authority-check statement?

will you please elaborate a bit more about how can run the security trace and check it.

Thanks for your help.

Thanks an Regards

Ajith

[thomas_jung]

>The only major difference between the first server and the second server is that in the first server the application was running with an HTTP url and in the second server it is running with an HTTPS url.Whether this is going to have such an impact in case of the authority-check statement?

Absolutely not. The application has no idea at this point that HTTPs was used.

>will you please elaborate a bit more about how can run the security trace and check it.

A security admin should know how to perform the trace. You should talk to yours. This is a common thing to do for such troubleshooting regardless of WDA or not. Anytime you can't have the user run SU53 or have false positives you generally have to trace to see why. A ST01 system trace with authorization check option turned on will help a lot - but you should involve a security expert to help interpret the results.

[vineetrrakesh]

Hi Ajith,

Normally this should work, Have you checked the two users at the second server?

It could be possible that the users have different roles but your auth-object is included in both users in different roles (check composite roles as well).

Regards

Vineet