HTTP defines the status 401 Unauthorized for missing authentication, but this status only applies to HTTP authentication. What status should I return with a session cookie based system, when an unauthorized request happens?
1
-
This question is similar to: 403 Forbidden vs 401 Unauthorized HTTP responses. If you believe it’s different, please edit the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.TylerH– TylerH2025-04-04 13:54:12 +00:00Commented Apr 4 at 13:54
Add a comment
|
2 Answers
Formally, 403 Forbidden is the right response. It's defined as
Authorization will not help and the request SHOULD NOT be repeated.
The confusing part may be "Authorization will not help", but they really mean "HTTP authentication" (WWW-Authenticate)
5 Comments
Erik Philips
This means the user should not EVER attempt the request again. This is not appropriate.
userx
Technically, I believe you are correct. In the case of practical implementation, I believe a 200 with an HTML based error message or 302 redirecting to another page where session based login can occur is more common (and perhaps arguably more useful).
userx
@Erik Philips - This is correct, the request shouldn't be. Once the headers of the request are altered to have a correct session cookie (hence not the SAME request), access will be granted.
JakubKnejzlik
I don't know if it's not misleading to strongly reference the authorization METHOD. IMO it doesn't matter if the authorization is transferred over cookies or header field, the critical information of the status code is if the reason of the failure is due to unauthorized request (token expired/not specified – 401) or if the user is not approved to access this resource and there is no way to change it with his "account" (403).
Bergi
403 I believe is technically correct (and probably most effective if you are implementing a custom API / protocol).
401 is not appropriate as it refers to authorization with a WWW-Authenticate header, which a session cookie is not.
If this is a public facing website where you are trying to deny access based on a session cookie, 200 with an appropriate body to indicate that log in is needed or a 302 temporary redirect to a log in page is often best.
2 Comments
Julian Reschke
This would be fixable my actually defining a cookie-based HTTP authentication scheme.
userx
@Julian Reschke - Well cookies don't by definition have much to do with authentication; primarily, they are adding some amount of "state" to a "state-less" protocol, HTTP. Cookies themselves don't authenticate anything. They are simply information being sent to a server which that server previously asked the browser to save. Yes, that information can be used for determining if you previously were authenticated as a user (typically via HTTP POST / GET). It also can simply be used to indicate whether you've seen a particular ad before, or visited that site before and when, etc.