Security 401 unauthorized vs 403 forbidden

[dumbNickname]

Hi,

I have noticed that HTTP security interceptor is sensible only for HTTP 403 (Forbidden) responses. How can we distinguish two scenarios:

• user tries to execute some action against server/obtain a resource when he is not logged in
• user tries to execute an action/obtain resource and he lacks privileges/rights to do so. What will currently happen if e.g. button/component is mistakenly shown to a user not belonging to the group having access rights to execute underlying action and the user clicks this button? Is 403 returned in such case? If so, the user will be prompted to log in, even though he already has a valid session. I would propose to introduce usage of HTTP 401 response status in case of an attempt to obtain resource when a session does not exist (or has expired) and 403 response status for resources with missing access rights. What do you think?

Cheers, Bartek

[feimosi]

Actually the interceptor should be configured to handle only 401 status codes. There's no sense in displaying the log in form for forbidden resources, a redirection is the best solution. Also, IMHO the user should never be able to request a REST resource he doesn't have access to. If it happens it's the application's bug. Cheers

[dumbNickname]

Hi.

Thanks for your answer. One small clarification form my side - I only stated that consistent and well defined handling should be established for both: HTTP 401 and 403. I did not encourage to show log-in dialog for forbidden resources. The main point was that 403 should be handled separately from 401. Redirection to an error page is one of the possibilities, another would be an interceptor for some common error modals (also for internal server errors etc.) :)

I fully agree that client application should make it impossible to face problems with forbidden resources, but still it should also have a common backup mechanism to inform user about problems instead of hiding those silently - even if caused by bugs, programming mistakes etc. In the end what matters for the user is that he cannot complete an action and he/she would probably like to know about it. Besides it is common for applications to have bugs at some development stages :P

There are also some tricky cases like: user logs in as a waiter on first browser tab, then opens second tab, logs out and logs in as a cook. It is possible that on tab 1 there are still some buttons visible, that cook cannot access due to privileges restrictions. Also the CSRF token stored in tab 1 will be now invalid ... what can be obviously handled in a reasonable way, but if nobody thought about such a use case in the first place, the server will very likely throw some errors. Cheers, Bartek

[feimosi]

Hi, sorry, today I've just realized that OASP registers its own interceptor for HTTP 403, which caused unexpected behavior for forbidden resources in my application. So you're right. There always should be both interceptors: for 401 and 403 errors. But OASP-security is designed to handle 401 Unauthorized (Unauthenticated actually) responses. Therefore I think it's a design misconception and best way would be to disable that interceptor (quite easy in Angular) and implement your own.

That's true, it's good to inform users about any encountered errors, just not to put much code bloat into this logic, for forbidden resources, a redirection is a good way out :) And nice use case, as rare as it could occur, still good to think about it. In case it could happen more often, maybe a good idea would be to validate sessions for 403 responses.

Cheers, Marek

[dumbNickname]

:thumbsup: (The unexpected behavior for forbidden resources, that you mentioned, was exactly what I had in mind when opening this issue.)

[hohwille]

I do not understand? Why would I cause a redirect on 403 in the client? A 4xx is an error and there has to be a central error handling in the client. This should raise a popup or growl message but no redirect.

[jkokoszk]

In my opinion this was solved with PR #54 that's why I close this issue for now. @mmatczak: Could you please double check it and reopen it in case I'm wrong?