Domanda

I'm creating a system with a JavaScript client that will communicate with the server over REST (HTTP)[JSON].

I am using role-based access control to manage the calls.

Example: [explicit URL will stay the same]

  • Anonymous -> request \
  • Server -> route to login form: \login\
  • User (now with cookie!) -> request \
    • if (user->role == "manager") return "\manager-homepage\";
    • else return "\homepage\";

Since REST is stateless how would I go about managing this use-case?

Do I send the cookie with each request, and the returned HTTP status codes will tell the JS where to route?

[Which would be rather inefficient + open to MITM attacks]

È stato utile?

Soluzione

Can you not use a standard authentication scheme, such as http digest?

Example: [from Wikipedia page]

  • The client asks for a page that requires authentication but does not provide a username and password. Typically this is because the user simply entered the address or followed a link to the page.
  • The server responds with the 401 "client-error" response code, providing the authentication realm and a randomly-generated, single-use value called a nonce.
  • At this point, the browser will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a username and password. The user may decide to cancel at this point.
  • Once a username and password have been supplied, the client re-sends the same request but adds an authentication header that includes the response code.
  • In this example, the server accepts the authentication and the page is returned. If the username is invalid and/or the password is incorrect, the server might return the "401" response code and the client would prompt the user again.

Note: A client may already have the required username and password without needing to prompt the user, e.g. if they have previously been stored by a web browser.

See also this answer to a very similar question: REST and authentication variants

Depending on your desired security level, you could serve the whole thing over ssl. That will prevent mitm attacks.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top