I read that "401 Unauthorized" code must be used when a user:
- Is not logged, but login is required ("not authenticated");
- Is logged, but his profile don't allow to see that url ("not authorized");
According to RFC, in both cases server must return 401
code.
But I need to differentiate then in my ajax requests.
Anybody have a tip to solve this?
Note: I don't want to use 403 Forbidden
code, because in 403 "Authorization will not help"
, according to RFC.
You should pass a custom header in addition to the status code for application specific needs.
I believe the current practice is to preface custom headers with X-
Update, August 2012:
From the RFC 3864 posted in the comments (dated September 2004):
In some cases (notably HTTP [24]), the header syntax and usage is
redefined for the specific application.
[...]
In some cases, the same field name may be specified differently (by
different documents) for use with different application protocols.
[...]
We need to accommodate application-specific fields, while wishing to
recognize and promote (where appropriate) commonality of other fields
across multiple applications.
In a more recent RFC (6648, dated June 2012), they specifically address X-
headers.
Deprecates the "X-" convention for newly defined parameters in
application protocols, including new parameters for established
protocols. [...] Does not recommend against the practice of private,
local, preliminary, experimental, or implementation-specific
parameters, only against the use of "X-" and similar constructs in the
names of such parameters.
Important to note is that while X-
is specifically noted, they do still implicitly condone custom headers as a way of transferring information. An application specific prefix (MyApp-
) might be more appropriate to avoid ever colliding with any other headers.
See also: Is it safe to use "X-" header in a HTTP response from a few years ago.
Unless you intend to use HTTP authentication, the correct response is 403 ("Forbidden").
A response code of 401 triggers the browser to display a password dialog box, and then resubmit the same request with a WWW-Authenticate
header with the password data that the user supplied. That's probably not the behavior you want.
Don't get too hung up on the explanations in the RFCs -- what you really need to pay attention to are the browser and search engine side effects of the various response codes.
As for the "Authorization will not help"
bit, in this case that is correct, since using HTTP authorization (which specifically means the WWW-Authenticate
header), in fact, will not help.
A 403 response tells the browser that the user does not have permission to make that request, and the browser should not attempt to collect authentication data and resubmit the request. That's exactly the response you're after.
I believe 403 is the right one. We may have to tune the language in the specification to make that clear.
IIS differentiates these cases with sub-status codes (reference):
- 401 = User is not logged in, but login is required
- 401.1 = The user tried to login but their credentials are not valid.
- 401.3 = The user's credentials are valid but the user is not authorized to see the resource.