I have a web application that uses RESTful url patterns. Currently if a users tries to access a page where they need to be authenticated it just returns nothing. Is it good practice to return the HTTP status code in this case? Would I use 403 or a different one?
You should send a response with the HTTP status code.
I wouldn't send a 403 Forbidden back though as the spec specifies for this status code :
The server understood the request, but
is refusing to fulfill it.
Authorization will not help and the
request SHOULD NOT be repeated
Return a 401 Unauthorized status code instead. See this for more info on the status codes:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
The way I do this with Jersey is to send a response with the status and then include a String entity which contains a human readable message, e.g.
Response response = Response.status(Status.PRECONDITION_FAILED).entity(
new String("Incorrect " + id + " [" + id + "]")).build();
This will be displayed to the client. I throw a Jersey WebApplicationException which wraps this response.
If they don't have permissions return 401 to give them the chance to respond to the authentication challenge or 403 if you don't want them to.
Restlet 1.1 onwards return 403, while earlier versions return 401. 403 seems to be regarded as more correct, if not necessarily more helpful.
It depends. You really ought to return something, of course, just to have a decent client experience. If you'd like to give them opportunity to authenticate at that moment, you can return a 401 and the client will know to pass credentials using standard authentication. If, however, you'd prefer that they authenticate through some other mechanism (some login URL and then set a cookie or somesuch), then returning a 403 is probably the way to go.
lol... in the REST API implementation I just built I returned a 401 status code with a response body that read "goodbye". Was the first thing complained about by guy interacting with API. I still think "goodbye" said it all ; )
Related
I am wondering what the best practice for the following scenario is: I have an application where an agent authenticates on behalf of a customer.
If the customer is banned, what is the best practice for the http status code I return them?
When I return a 403 it seems as if the request they made was invalid, it does not convey to the agent the user is banned. In the same sense I do not want to send a 401 unless the credentials used to make the request were invalid.
I have read a few answers and the spec and haven't found what I was looking for. I was leaning towards a custom 2XX response i.e (230) or something like 406 or 451.
Looking forward to your input.
Resources used:
https://racksburg.com/choosing-an-http-status-code/
https://httpstatuses.com/
What is the best HTTP status code for blocked user profile in rails api?
In my opinion, you should stay with the standard: 403.
From: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
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. If the request method was not HEAD and the
server wishes to make public why the request has not been fulfilled,
it SHOULD describe the reason for the refusal in the entity. If the
server does not wish to make this information available to the client,
the status code 404 (Not Found) can be used instead.
Returning FORBIDDEN is very straight forward as the the other codes may be perceived as ambiguous.
I have a client coded in JavaScript. This client calls an API method on my server which is coded in PHP. This API method is "GET /user" and could return a 200 status or a 204 status.
The 200 status is intended for authenticated users.
The 204 status is intended for guest users and can in the future become a 200 with information about these guest users (like frontend autorizations).
I had a confrontation with developers who think my API should return a 401 status in case the user is a guest. But I said there was no client error since the client just ask for the authentication state + some information about the non guest user.
So my question is pretty simple: is there a missconception in my API ?
I would suggest neither.
Take a look at section 10 of the HTTP/1.1 RFC and see if you can match your response code with what is being returned.
If you are returning data from GET /users (regardless of authenticated client or guest) then 204 No Content is not appropriate:
The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
A 401 Unauthorized is only appropriate if the method being called is only accessible to authenticated clients. You are essentially telling the client that they have done something they are not allowed to.
If both an authenticated user and a guest user are expected clients of your API I would suggest returning a 200 OK to both clients and have any differentiation made clear in the returned body itself.
I totally agree with the answer of #Johnson. Do not change the meaning of the status codes. If it is a valid request, you should respond with 200.
The problem here is that the endpoint you define is not a resource-oriented endpoint (problem = REST API design guidelines are not really applicable as they are mostly focused on resource oriented APIs). /user in your case seems to return a state rather than a resource. 401 is good for telling the client that it is not authenticated and thus cannot fetch the requested resource.
In your case it is just an informative endpoint for the client to check its login state and both states (logged in and not logged in) are successful answers from a technical point of view and thus require a 200 response. To tell the client the login state you should use the response body, not the status code.
I have seen the list of all HTTP status codes.
However to me it looks like there is no code for "email not verified" (used for authentication/authorization).
Did you ever had the same "problem"? What HTTP status code did you use?
I guess it should be a code starting with a 4 as it's a "client error".
The 4xx class of status code is intended for situations in which the client seems to have erred:
6.5. Client Error 4xx
The 4xx (Client Error) class of status code indicates that the client
seems to have erred. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent
condition. These status codes are applicable to any request method.
User agents SHOULD display any included representation to the user.
For authentication and authorization, 401 and 403 are the proper status codes to be used, respectively. Regardless of the status code, you should always describe that reason of the error in the response payload.
401 Unauthorized
Use this status code for problems with HTTP authentication, that is, invalid credentials.
3.1. 401 Unauthorized
The 401 (Unauthorized) status code indicates that the request has not
been applied because it lacks valid authentication credentials for
the target resource. The server generating a 401 response MUST send
a WWW-Authenticate header field containing at least one
challenge applicable to the target resource.
If the request included authentication credentials, then the 401
response indicates that authorization has been refused for those
credentials. The user agent MAY repeat the request with a new or
replaced Authorization header field. If the 401
response contains the same challenge as the prior response, and the
user agent has already attempted authentication at least once, then
the user agent SHOULD present the enclosed representation to the
user, since it usually contains relevant diagnostic information.
403 Forbidden
Use this status code for problems with authorization, that is, the credentials are valid but they are insufficient to grant access.
6.5.3. 403 Forbidden
The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to
make public why the request has been forbidden can describe that
reason in the response payload (if any).
If authentication credentials were provided in the request, the
server considers them insufficient to grant access. The client
SHOULD NOT automatically repeat the request with the same
credentials. The client MAY repeat the request with new or different
credentials. However, a request might be forbidden for reasons
unrelated to the credentials. [...]
While CodeCaster has provided a very definitive answer as a comment, that which is correct is sometimes not appropriate.
Firstly, you'll see there is no mention of email addresses in the specs. Similarly there is no mention of shoe sizes, model railway gauges, breeds of dogs nor many other things. It is not relevant to HTTP. This is just a data item.
You seem to have some state associated with this data item which you use for authentication purposes - but don't provide any explanation of that state nor how it is applied. I assume that you mean that the "not verified" state means that the only association between the data item and the user interacting with your site is an assertion of the user. And further that you do not allow the user to authenticate with this as a token.
It may seem I'm being pedantic here - but there are other, valid interpretations of "email not verified". You should have provided more information in your question.
There's another gap in your story: which request are we taking about here? Again, I'll take the liberty of assuming that the request is an attempt to authenticate.
In this case, there is nothing intrinsically wrong with the request. There is nothing intrinsically wrong with the client. There is nothing intrinsically wrong at the server. Not permitting the user to authenticate is a policy decision based on the data.
Another critical bit of information missing from your question is what is actually making the request. If its a form sent by a browser, then returning anything other than a 200 OK (or 204, or a redirect to a 200) to MSIE will, by default, cause the browser to display an internal message and not the content you send.
OTOH if the client is an application running on the users device, or an Ajax request, then you control the API and can define your own semantics. If you want to return a 692 status code to represent this condition, then you can return a 692 error code. You can even inject your own headers in the response (by convention these should begin with 'X-').
In the defined state the authentication fails. But returning a 401 response will prompt a browser to attempt HTTP authentication - which doesn't address the issue.
IMHO, the nearest existing code is 403 or 422. But based on the information you've supplied I can't say if thats what you should be using.
I'm creating some restful apis. There is a "register" api, user can POST an "email" and "name" and "password" to register.
On the server side, I will check if the email has been used first. What http code shall I response if I found the email has already been used?
I response 400(bad request) for now, but I don't know if it's correct.
400 Bad Request is correct since there's no specific HTTP code for validation errors.
In a REST API, in general you only ever need to return four HTTP error codes:
401 for unauthorized access
404 for unknown resources
405 for unsupported methods (eg. GET is available but not POST)
400 for everything else
An authentication service allows user accounts be disabled (a sort of soft-delete).
If the server then receives an authentication request for a disabled user that would otherwise be valid, should the server return 401 or 403? With either status code, I would return a message indicating that the account had been disabled.
For quick reference, relevant quotes from HTTP/1.1 spec (emphasis mine):
401 Unauthorized
The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource. The client MAY repeat the
request with a suitable Authorization header field (section 14.8). If
the request already included Authorization credentials, then the 401
response indicates that authorization has been refused for those
credentials. If the 401 response contains the same challenge as the
prior response, and the user agent has already attempted
authentication at least once, then the user SHOULD be presented the
entity that was given in the response, since that entity might
include relevant diagnostic information. HTTP access authentication
is explained in "HTTP Authentication: Basic and Digest Access
Authentication" [43].
403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. If the server does not wish to
make this information available to the client, the status code 404
(Not Found) can be used instead.
Based on an email written by Roy T. Fielding, there's apparently a bug in the current HTTP spec.
The way the spec is intended to be read is as follows (using quotes from above email):
401 "Unauthenticated":
you can't do this because you haven't authenticated
403 "Unauthorized":
user agent sent valid credentials but doesn't have access
So, in the case of a disabled user, 403 is the correct response (and 404 is also an option).
I've got two different answers for what to return in this case.
Semantic choice - 401 Unauthorized. In this case, your client has provided credentials, and the request has been refused based on the specific credentials. If the client were to try again with a different set of credentials, or if the account were to be re-enabled in the future, the same request might succeed.
Security choice - 404 Not Found. Many services will simply return a 404 for any failure, in order to avoid information leakage. Github comes to my mind immediately.
From General API Information, in github's developer docs:
Unauthenticated requests will return 404 to prevent any sort of
private information leakage.
For something I was deploying as a public service, I'd probably go with using 404 to avoid giving an attacker clues about their credential attempts. If it was for internal-only consumption, or in testing, I'd probably return 401.
technically both are correct, it really comes down to how much you want to reveal.
returning a 401 says to the caller that the account isn't valid, which is correct, but if your api is then going to be called again to register a user with the same credentials that call would also fail. which might not be much use to the caller.
so, it really depends on how your api will be used and who/what the target audience is.