When creating a web service (RESTful), what status code should I use when session token is invalid?
Currently the one in my company sends me a 404, not found, but I think this is not correct, because the resource exists.
Maybe I should use 401 Unauthorized.
What do you think? What status code do you recommend me to use in this scenario? Thanks.
401 Unauthorized.
Your existing session token doesn't authorize you any more, so you are unauthorized.
Don't forget that a session token is just a short-cut to avoid having to provide credentials for every request.
Sending 404 is incorrect because, as you observe, the resource does exist. You just don't currently have authorization to see it.
NB Don't use 403 Forbidden; the HTTP specification defines it as follows: "The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated." That doesn't apply in this case as authorization WILL help.
Looking through the HttpStatusCode enum, I think Unauthorized is probably the closest to what you're looking for.
Take a look at the list there, and read the descriptions for each one.
Related
I am implementing an Ocelot gateway. When I make the API call using my browser to http://localhost:5009/api/values, I get a valid json response back. However when I make the same request through Postman I get a 401 Unauthorized response. Any ideas if there is a setting in Postman I need to change or something else.
That is, the client must authenticate itself to get the requested response.
Most likely you have forgotten to put your token to the Header in Postman to be authenticated for the server in order to get a response.
I'm trying to make a request from my reactjs app existing on "localhost:3000" to my django living in "localhost:8000"
I was expecting some authentication token in header to passed along with the request, but it's not the case. The request seems to be stripped and the token is nowhere to be found. Unless I pass the token in the url as a parameter (which exposes the token that can be decoded. I don't like it), I can't seem to be able to get the token in any way.
so my questions:
is this CORS issue? My understanding is that CORS usually deals with javascripts only, and Django already has the middleware to deal with this.
I'm currently using a GET as method. Does using a POST help in this case? How would the reactjs script be written? Currently it's just a href attached to a NavItem
and ultimately:
How do I pass the token from reactjs to django?
We can perform the implicit grant on the front-end and then configure the Django API in Auth0 and specify its identifier in the audience parameter. This would grant you an access token which you could then use against your API. Your API would then verify the token and check the audience is correct. (This has a good overview of the process https://auth0.com/docs/api-auth/grant/implicit and then with the API https://auth0.com/docs/architecture-scenarios/spa-api)
Basically what we can do is when Auth0 authenticates the user it redirects the user to the app with an access token, and optionally an id token, in the hash fragment of the URI. We can extract that and use the token to call the API on behalf of the user.
So, after we have [created the API in Auth0][3, [defined the endpoints]3, and secured the endpoints we can call the API (by sending the access token in an Authorization header using the Bearer scheme).
If you have any Auth0 specific question please feel free to join over in community.auth0.com you may have better luck finding help/solutions.
The 403 error is telling you that the request is not being processed because something is stopping from process that request 403: The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated
As you said probably because the CORS, try to follow the guide bellow of how to install Django-cors
https://github.com/mbrochh/django-graphql-apollo-react-demo#add-jwt-authentication-to-django
I have setup my API at Amazon API Gateway and the Gateway Responses part seems to be a bit confusing.
There are a lot of default responses defined here along with the HTTP Return Code:
Access Denied (403)
Invalid API Key (403)
Invalid Signature (403)
Missing Authentication Token (403)
Unauthorized (401)
Is there any logic of which response is returned upon which condition? I have done my tests and I wasn't able to find a pattern.
No API Key + Valid URL: Invalid API Key
No API Key + Invalid URL: Missing Authentication Token
Good API Key + Invalid URL: Missing Authentication Token
Is there any specific pattern here?
Thanks,
Guven.
As noted in comments, for security reasons, API Gateway can give you the impression that it is really pretty obsessive about these mysterious authentication token thingies, whatever exactly they may be.
But this was apparently done because it should be difficult for a malicious user to determine a specific reason why the request is forbidden... and, as you have discovered, this message is as potentially uninformative as it is potentially misleading. (Not necessarily a criticism, here... that's what it's for.)
What you'll probably find helpful is to go in and customize your error responses and change the default wording of each message to match its actual meaning. There are several where you'll find Missing Authentication Token in the text of the template.
I'm giving flask-security a go...it has a lot of nice pieces to it. I ran into some quirky behavior though that I don't really understand. From the code I looked at it looks very intentional that the code works the way it does, but I can't understand the rationale.
If you protect a view using #auth_token_required and the criteria is not met a 401 is returned. Makes perfect sense.
However, if you protect a view using #roles_required and the criteria is not met, the server redirects (302) to an unauthorized view.
This makes no sense to me why they both would not behave consistently. Indeed in both cases I want and expect a 401.
Can anyone explain the reasoning and why I might want this? Or can someone explain the best way to customize the #roles_required behavior?
Thanks!
I believe this has something to do with the different levels of unauthorized responses. The first one being a 401 error and the second one for a 403 error.
Here's difference between the two:
In summary, a 401 Unauthorized response should be used for missing or
bad authentication, and a 403 Forbidden response should be used
afterwards, when the user is authenticated but isn’t authorized to
perform the requested operation on the given resource.
Source: 403 Forbidden vs 401 Unauthorized HTTP responses
I am designing a POST Restful API, where I have a situation that I have to authorize a user based upon one of the element provided in the request body.
For eg.
{
division : "1",
name : "MyName",
address:{
no : 123,
street : "abc",
pincode : 222111
}
....
}
So the user making POST request should be authorized to work on division 1. I cannot authorize the user without getting request body.
Also to validate some of the attributes I have to make heavy DB calls in the DB , for eg, to check the above address has a valid value of pincode.
So My question is how should I return the error codes to the user -
[EDIT]If division is not valid(something that doesnt exist in system) in the request - 400 or 403 ?
If division is provided, but user is not authorized and pincode is invalid - 400 for invalid pincode or 403 ?
What should be the error code if pincode is mandatory attribute and is not provided in the request. Should I first check 403 and then 400 or reverse ?
Basically which error code to proceed the other ?
Also is it okay to do something like :
400 – request is bad, syntactically (division/pincode or other mandatory values not provided)
403 – authorize user
400 – request is bad, data specific validation (heavier operation, requiring to hit DB)
[EDIT] we preferred not to use 422 error code
When in doubt, just take a look at the RFC
400 Bad Request
The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
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.
If division is not provided in the request - 400 or 403?
I don't think either apply. The syntax -although it's missing some data- is not malformed.
Also 403 seems incorrect because of reasons mentioned above in the quote: authorization will not help etc.
How about 422 Unprocessable Entity?
422 Unprocessable Entity (WebDAV; RFC 4918)
The request was well-formed but was unable to be followed due to
semantic errors.
That is what I usually use in situations like this.
If division is provided, but user is not authorized and pincode is invalid - 400 for invalid pincode or 403?
Again, I don't think either 400 or 403 make a good case here. Specifically for this situation, 401 exists
401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication
is required and has failed or has not yet been provided. The response
must include a WWW-Authenticate header field containing a challenge
applicable to the requested resource. See Basic access authentication
and Digest access authentication.
I think you're in the right track. Assuming that every request is being authenticated via (http authorization header)
Returning 400, on missing data is OK, and furthermore you can add error response body explaining what was the reason for the Client request not being accepted (in this case the missing division).
Returning 403, is OK if the client making the request is not authorized to interact with the resource (in this case the division).
You must validate first if the Client is authorized to interact with the resource, so 403 must be sent first, and if a required field is missing you can treat it as a 400 (with a proper explanation).
In case the Client is not authenticated, the correct response should be 401, but like I said before, 1) and 2) in my response are assuming that the Clients are authenticated against the server.
Hope it helps,
Jose Luis