The docs on Authentication state that:
Upon receiving a 403 response, the admin app shows the Login page.
This is wrong isn't it?
My understanding has always been:
Sending to a login page is only sensible if the user is not logged in yet. If 403 is returned, it means the user is logged in, but still not allowed access. He should first log out and then log in as a different user.
By default, if you provided an authClient a failed fetch will redirect to the login page.
However, you can customize it easily. See Catching Authentication Errors On The API.
My point was more that 403 effectively means 'you are logged in but do not have permission', so an error page might be more appropriate then a login page. But thanks anyway!
I agree with @Download . In my case, there is no real Login Form and I would like to show a pop-up / custom page saying user is not entitled when I get 403-Forbidden. Is that possible please?
Everything is possible, since it's your authClient that conveys the logout logic.
I did try Promise.reject({ redirectTo: '/no-access' }); and simply Promise.reject . But, the latter always redirects to the login page and not to custom No Entitlements Page.
And, moreover, it is not AUTH_LOGOUT. It is AUTH_ERROR. Any links to sample ?
Whenever you reject a promise in the authClient, it goes to the login page. If you want to add a custom redirection in reaction to a custom event, you'll have to add a custom saga.
_Redirection in reaction to a custom event_
I am not reacting to custom event. I am reacting to AUTH_ERROR and this type is a valid type in authClient. So, in AUTH_ERROR I want to redirect to custom page. How is the custom event related here ? I am sorry - I am not very clear.
Also, thanks for the reply, I commented on an already asked question on SO - https://stackoverflow.com/a/47527414/763026
Could you please answer that ?
How and where do you define this custom action ? Also in the sample link, where is definition for BITCOIN_RATE_RECEIVED i.e. how is this action being registered with Admin app ?
StackOverflow is the right place to ask "How To" questions, please don't cross-post here.
OK, may be 2nd part is a How to (and not many users are aware of AOR, hence response to SO answers become a bit longer wait even for simpler issues)
but could please clarify this (related to your earlier response) ?
_Redirection in reaction to a custom event_
I am not reacting to custom event. I am reacting to AUTH_ERROR and this type is a valid type in authClient. So, in AUTH_ERROR I want to redirect to custom page. How is the custom event related here to 'AUTH_ERROR' type ? I am sorry - I am not very clear.
You can't have a side effect in the authClient. The only way is to react to actions in a custom saga. AUTH_ERROR isn't an action, it's an auth verb. The action you should react to is FETCH_ERROR.
This is definitely a "how to" question, so please go to SO for further details.
@fzaninotto
My original issue still stands however:
Upon receiving a 403 response, the admin app shows the Login page.
This is simply wrong/unexpected behaviour.
Redirect to login page is expected upon 401 response:
10.4.2 401 Unauthorized
The request requires user authentication.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2
The meaning of 403 is that access is simply denied for the current credentials:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4
(emphasis mine)
I think this part of the HTTP spec is very vague and using wrong terminology, but the way it is being interpreted and used all over the web is 401 => Login, 403 => Auth error . Sending to a login page is confusing, because the problem is not that the user is not logged in (he is, otherwise server should send 401), but that he does not have permissions to do whatever it is he wanted to do. I think you can easily observe this behavior on many websites.
I've already answered that: handling of HTTP error codes is done by the authClient, therefore it's on your side. Admin-on-rest lets you do whatever you want. See e.g.
There is no instance of 401 or 403 in the admin-on-rest code.
I see this behavior with the default auth client.
EDIT: I guess your stance is that the supplied rest clients are just examples and the user of this library has to take responsibility for that part. Which I think is very reasonable. So I'll stop nagging you about it :)
Fantastic project BTW. I evaluated a lot of 'admin-screen' tools, but this one is both having a nice looking modern UI and is flexible in handling many APIs. Also it has sane defaults. You really are up and running very quickly with this project. Thank you for building/maintaining it!
Thanks a lot, much appreciated!
Most helpful comment
I see this behavior with the default auth client.
EDIT: I guess your stance is that the supplied rest clients are just examples and the user of this library has to take responsibility for that part. Which I think is very reasonable. So I'll stop nagging you about it :)
Fantastic project BTW. I evaluated a lot of 'admin-screen' tools, but this one is both having a nice looking modern UI and is flexible in handling many APIs. Also it has sane defaults. You really are up and running very quickly with this project. Thank you for building/maintaining it!