1

I read these excellent answers of this post: If REST applications are supposed to be stateless, how do you manage sessions? and few similar posts but I still have a specific problem with RESTful apps and sessions:

In an app where a user needs to log in to perform a request only once per month: is this feasible with a RESTful app?

I ask this because saving the session state on the server is forbidden within REST technologies but where can I save the last date the client performed the request so that I serve his request positively after checking the condition above (once per month). Or is this not feasible at all with REST tech?

UPDATE:

I first accepted the answer below but I remember I read this:

each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.

Also from the first link, it is answered that:

The client's application state should never be stored on the server

So my question is still the same. Please help

Community
  • 1
  • 1
Jeremy
  • 13
  • 3
  • database store different information potato green. – DwB Dec 31 '15 at 18:35
  • With REST, the request must be served without checking the prior state of the session: does not storing that info in the DB so that the service provider checks it before serving the request violates the REST principles? – Jeremy Dec 31 '15 at 18:47

2 Answers2

1

The session state that "stateless" refers to is not that kind of info. It only means that the server can't store what the current state of the client is. Nothing forbids storing the last connection date on the server. You can also store it on the client using LocalStorage for instance.

Ilya
  • 5,377
  • 2
  • 18
  • 33
  • But a REST request must be served without checking the previous state of the session: following your logic, the request will be served only after checking the last state of the session (date in this case) stored in the DB. So how to resolve this? – Jeremy Dec 31 '15 at 18:41
  • No, "previous state of the session" refers to the previous state of the current session, what happened last month is irrelevant because I guess that the user has to re-log each time (month) - so it's a different session. – Ilya Dec 31 '15 at 18:46
  • I am very sorry to unaccept your answer for the reason mentioned in my question (check my update) – Jeremy Dec 31 '15 at 19:07
  • I assure you that you can use data on the server, what is forbidden is to use a "current session" context. Beside, you're not using it to "understand" the request. Otherwise, you can store data locally on the client, but it's not as safe. – Ilya Dec 31 '15 at 19:15
  • You are right for the notion of *understanding the request* but I am still confused with the bold quoted text above (in the first link I provided a similar thing is stated by the most upvoted answer: **The client's application state should never be stored on the server**). Saving info on the client side is not safe as you said if the client clears his browser, I do not want to use that. – Jeremy Dec 31 '15 at 19:21
  • When you're storing or using the last connexion date, you're not using the state, you're using the history, that's completely different. – Ilya Dec 31 '15 at 19:26
0

The state of client is not what is at issue here but rather the credentials. Credentials are managed through Authorization schemes which typically generate a token in the form of a UUID which is passed with each request to identify the client. It is very secure if implemented on top of SSL.

The process looks like this.

  1. Client logs in with username+password.
  2. Server validates and returns a uuid/token.
  3. Client makes a REST request.
  4. Server looks at token in request
  5. Server looks up the token and determines if the token is expired.
  6. If the token is expired the server returns an http authorization error(401)
  7. If the token is not expired the server returns the data in a response.
Nathaniel Johnson
  • 4,731
  • 1
  • 42
  • 69
  • So the REST request must have the previously generated token by the server with it? – Jeremy Dec 31 '15 at 20:01
  • If you are using authentication then yes, at login. – Nathaniel Johnson Dec 31 '15 at 20:04
  • Good. But: does not the stored token represents a state of the session? – Jeremy Dec 31 '15 at 20:11
  • I'm sorry, I don't know what you are asking. Are you wanting to prevent the user from using the service more thn once per 30 days? – Nathaniel Johnson Dec 31 '15 at 20:14
  • Yes. The client can log in to the service, but must not be able to REST request it more than once per 30 days. (sorry for my bad English and thank you very much for your patience) – Jeremy Dec 31 '15 at 20:17
  • Invalidate the token with their REST call AND then store the user with last login date. When they try to log in again, disallow it. – Nathaniel Johnson Dec 31 '15 at 20:19
  • Yes, it solves the problem but: does not this action of storing the last login date represent saving the state of the session and thus breaking the REST principle the quoted texts in my question say? – Jeremy Dec 31 '15 at 20:21
  • No, the state that REST services shouldn't store relates to Transaction State for rollbacks and commits. Each transaction must be atomic and contain enough information to process the request. You would not be violating that. – Nathaniel Johnson Dec 31 '15 at 20:25
  • 1
    Thank you very much for your great patience. Wish you all the best for the new year. Regards – Jeremy Dec 31 '15 at 20:26