Friends and fellow users,
We have both 402 and 403 http response codes. Though, 402 is reserved for future use.
What is (or would be) the difference between these two. Payment not received should be equal to not authorized, shouldn't it?
EDIT:I would like to know the answers on a "Why 402 is required when we already have 403" angle.
The HTTP Statuscode 402 is indeed different from 403:
As it states in RFC 2616 the status code 402 is
402 Payment Required
That means the request is not generally forbidden but requires payment.
Apparently it is used by some services in the intended manner List of HTTP status codes
I think it is currently not needed (or just not used because not specified how to use) but the authors of the standard did some thought an put it in for future use which could be useful.
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.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Dots this help?
Note that missing a payment is only one reason to your server deny a request. You can get the "forbidden" status in other situations such as, invalid credentials, trying to access to a "private resource", etc...
I belive 402 exists just to give any more details about the reason to deny a request.
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 am building an API and I am returning this kind of status codes for each method (e.g., "register_user"):
200 (OK) when the user has been registered successfully
403 (forbidden) when there are missing parameters in the request
409 (conflict) when a user was already registered
In addition to the status code, I return a "message" field explaining what happened. Do you consider returning these codes in this example a good practice? Or should I return 200 in all of them but an error in the "message" field?
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).
-- RFC 7231, 6.5.3
That doesn't sound like what you've got at all. The other two are reasonable. Missing parameters are typically handled with a 400 response code.
The website I work on temporarily bans users after suspicious behaviour is detected. Currently the user is bounced to a page that has minimal UI and a message telling them their access has been denied.
This page currently returns a response code of 200 and I'm about to change it to 403 as I believe this could help alert spam bots that they've been blocked.
So, in short, the page will remain exactly as is, the functionality will not change, only the response code will change from being 200 -> 403.
Is this advisable or am I potentially going to cause problems that I do not anticipate?
Sounds reasonable to me, per the definition of 403:
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.
What is the difference when we use 200 response status code for a forbidden page with an error message saying 'Access Denied' instead of using 403 response status code?
Are there any security implications?
The HTTP Response codes convey information about how the server has processed your request. So, if the server responds with 200, it means: "OK, I have received your request and processed it successfully". If it returns 403, it would mean: "I received your request successfully, but you don't have access to this resource".
However, technically they are both returned in the same format, in the same way in the response HTTP header like this:
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
The difference is in the meaning. And the meanings are defined in the standard.
So, when you are responding with code 200, you are telling the client that it is all good and dandy. If you are responding to client with 403, you are saying that the client doesn't have permission to this resource. Remember, there can be different clients: web browsers, crawlers, ajax requests from javascript, etc.
So, if you are sending a login form with 200 code:
Users who are using a web browser would understand that they need to login.
Google crawler will index your members/quality-content URL with the login form and will not understand that actually, the original content is different and it should not index this page with the login form.
Javascript with ajax callback will run success callback, when it should be running error callback function.
So, basically, make us all a favour and follow the standards! :)
Answering your second question, no it does not make your application any less secure.
The reason for this decision might be that error message was not visiable using Internet explorer like described here: How do I suppress "friendly error messages" in Internet Explorer?
Actually the correct way is to use the right HTTP error code and make the error message longer than 512 bytes as described here:
https://support.microsoft.com/en-us/kb/294807
Response status codes are intended to help the client to understand the result of the request. Whenever possible, you should use the proper status codes.
The semantics of the status codes are defined in the RFC 7231, the current reference for HTTP/1.1.
While the 200 status code indicates that the request has succeeded, the 403 status code indicates that the server understood the request but refuses to authorize it:
6.3.1. 200 OK
The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. [...]
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). [...]
Returning 200 will work, for sure. But why would you return 200 if you can return a much more meaningful status code? If is there any good reason, this should be added to your question.
Leaving aside the question of whether or not you should return "helpful" http status codes to someone who is spamming you, what would the appropriate http response code be in this situation. Let's say that you are scanning the form for blacklisted words and the submission has some.
403 Forbidden seems like the most appropriate code. The description from RFC 2616 says:
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.
A better option may be the new 422 Unprocessable Entity code, defined in RFC 4918.
The 422 (Unprocessable Entity) status code means the server
understands the content type of the request entity (hence a
415(Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct (thus a 400 (Bad Request)
status code is inappropriate) but was unable to process the contained
instructions. For example, this error condition may occur if an XML
request body contains well-formed (i.e., syntactically correct), but
semantically erroneous, XML instructions.
This blog post recommends it for situations like yours, where there's a semantic problem with the posted content, rather than a syntactic problem.
For me for SCAM or SPAM fits best HTTP 451.
HTTP 451 Unavailable For Legal Reasons is a proposed standard error status code of the HTTP protocol to be displayed when the user requests a resource which cannot be served for legal reasons, such as a web page censored ... The RFC 7725 is specific that a 451 response does not indicate whether the resource exists but requests for it have been blocked, if the resource has been removed for legal reasons and no longer exists, or even if the resource has never existed, but any discussion of its topic has been legally forbidden.