I was reading through the simpy source code, and I found that for some reason, Request is a subclass of the Put class. Is there a reason for this? I thought a request was a request to get something out of a resource, not to put something into one?
The idea/abstraction behind this is, that Resource has a "shelf for user tokens". If a user wants to use the resource, they tries to put their token into the resource. They uses the resource until they removes the token.
If the shelf is already full, new users have to wait until they can place their tokens in it.
Related
I'm giving NestJS a try and am pretty happy with the results so far. Right now I'm struggling with some concepts that aren't clear enough in my head.
My API has an authorization-token in the format of a cookie (NOT A JWT). When the API receives a request, it has to use said cookie to ask another service (async), which user is sending it and what role he has.
This exchange from cookie to user info should prepend any controller logic and should be applied globally.
I think this can be done via a middleware, an interceptor or a pipe, but which of those is considered the better way according to NestJS?
Honestly, I would use a guard for this kind of feature. Check if the cookie exists, if not, there's already a problem, send back a 403 (i.e. return false). Otherwise, the rest of the logic can follow and you can attach the information to your req object, thereby having it available throughout the rest of the request. As guards are the first of the enhancers to fire, this also ensures that the value is available in interceptors and certain pipes.
I have an API method where the authentication server allows an automatic registration when the user does not exist yet on first login.
The auth server would make a call to:
PUT https://some-api/api/v1/auth/users
The handler of this method will check if the user already exists, and create it when the user does not based on email.
My question is whether there is something inherently wrong with not specifying the id in url upfront. The problem being that in fact, there is no userId yet when the user does not exist.
I know that the usual format would be:
PUT https://some-api/api/v1/auth/users/:userId
Obviously the client can check whether the user exists based on email upfront, create a POST request to create the user, or GET if the user already exists.
This introduces more network requests so I'd prefer to avoid this.
I noticed that there is some common solution to use 'email' as resource identifier.
This works for me. One remark is that I do not particularly like to use an email address in the url, but in my case it is okay as this url will only be visible within the cluster, and is not exposed to the outside network.
I have to create a middleware API which a functionality to check for a key present in my database. If the key exists then it should simply fetch it(GET method). If not, then the API should create the key and its value in the database and return that(POST method). So since we have 2 fundamentally different methods being combined in this API, is it correct to do so? What should be the best way to design such API?
Don't combine them.
Return zero results from your GET method if you the record doesn't exist. Then in the client, if you receive zero results, POST the needed information to another API endpoint.
Combining the two ideas into one will create a hard to understand system. Your system should be deterministic, i.e. you can always know the result of every call before you call it.
One way to look at your API is to forget about the underlying database, but think about how an API client uses it.
If an API client does a GET request, 2 things happen:
The existing record is returned
A new record is created and is returned
A client might not actually care if 1 or 2 happened. For the perspective of the client, it might look like the resource always existed (even if it was technically just created).
So as long as there's no extra information that must be sent along with a POST request, it might be fine to use a GET request for both cases.
I don't know about your situation, typically it is best to have your get and post seperated. Though, if your client thinks that it needs to create a record and then posts the data, i dont see the problem with returning the resource and a 409 for the resource already existing. Here is a similar question HTTP response code for POST when resource already exists
Then the client can handle the 409 differently or the same as a 200 depending on your needs.
Background
I'm having a trouble with the design and implementation of a REST service which publishes content that some users cannot view (medical information, you know, country's laws), I'm using a ABAC-like/RBAC system to protect them, but what causes me concern is that I may be violating the REST pattern. My services does the following process for each query:
The security middleware reads a token from a session that an app/webpage sends using authorization header or cookies.
ABAC/RBAC Rules are applied to know if user can access the resource.
After authorize the token, my service executes the query and filters the results, hiding content that requesting user cannot see (if needed. POST, PUT and DELETE operations are almost exempt from this step). The filter is done using ABAC/RBAC rules.
An operation report is stored in logs.
I already know that sessions violates REST pattern, but I can replace it using BASIC/DIGEST authorizations. My real question is the following:
Question
Does hiding resources from list/retrieve operations violates REST pattern? As far I know, REST is stateless, so ... What happens if I use some context variables to filter my results (user id)? Am I violating REST? Not at all?
If I do, What are your recommendations? How can I implement this without breaking REST conventions?
First of all, client-side sessions don't violate REST at all. REST says the communication between client and server must be stateless, or in other words, the server should not require any information not available in the request itself to respond it properly. If the client keeps a session and sends all information needed on every request, it's fine.
As to your question, there's nothing wrong with changing the response based on the authenticated user. REST is an architectural style that attempts to apply the successful design decisions behind the web itself to software development. When you log in to Stack Overflow, what you see as your profile is different from what I see, even though we are both using the same URI, right? That's how REST is supposed to work.
I'd recommend returning status codes 401 (Unauthorized) if the user is not authorized to access a resource. And 404 (Not found) if you cannot confirm that the resource even exists.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4
A GET is meant to return a representation of the resource. Nowhere does it say that you must return everything you know about that resource.
Exactly what representation is returned will depend on the request headers. For example of you might return either JSON or XML depending on what the client requested. Extending this line of thinking; it is ok to return different representations of a resource based on the client's authentication without violating REST principals.
A client sends the following to POST /account/register
{
"username": "user123",
"password": "pa55w0rd"
}
The server attempts to create the new account but finds that the username is already taken.
What should the most appropriate HTTP status code response be?
I'm thinking 409 Conflict however that means the client is then aware that the username exists, which might be a security issue? Or is it simply a case of visibility based on the type of site so depends on the situation?
I'd suggest returning error 409 Conflict:
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request.
If your are concerned about privacy, regardless if the account was created or not make sure to respond the same way, and probably 204 or 202 are the most appropriated status code in this case.
To not confuse the user on the frontend you can display a generic message saying something like "You will receive a confirmation email on the next minutes if you don't have an account, if you don't receive the email try forget password".
Depending on how far you want to take things, you might want to create the account on a background process rather than in the main/request thread, otherwise attackers could analyze the response time of your endpoint and infer if the account was created or not based on the response time, this since the process of actually creating the account might take more time than just checking if it exists and returning.
Responding the same way in both scenarios is the only way to ensure an attacker can't figure out who is already registered in your system.
Doesn't seem there's one. Maybe 406 Not Acceptable?
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
For user already exists 403 seemed perfect according to wikipedia
https://en.wikipedia.org/wiki/HTTP_403