5 ms·

Living Without Sessions

26 points by rams 18y ago

lisp_padawan 18y ago
an interesting read but one thing I didn't understand, how is one meant to save the plaintext username & password client side (so as to be able to send them with each request) without putting them in a cookie or requiring that the user's browser is set to 'remember this password' - anyone got any ideas?
- mtts 18y ago
  I think the point is not that no session state at all should be stored client side, but that most session state should not be.
  - alan 18y ago
    Actually, Peej is a REST fan. He's saying that if there's session state it should be on the client side. There should be none on the server side.
- shutter 18y ago
  That's authentication/authorization info; it should/must be stored on the client.
- DougBTX 18y ago
  In theory by using a cookie which can be verified by any server, but which can only be generated with the user's password (which is never stored in clear text). There is an article here, http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/ http://www.lightbluetouchpaper.org/2008/05/16/hardened-state... but the PDF link seems dead.
- briansmith 18y ago
  Browsers have that functionality built in as long as you are using RFC 2617 authentication.
  - newt0311 18y ago
    In theory. What about in practice?
    - eggnet 18y ago
      In my experience, the browser doesn't reliably send the username and password with each request so you get a bunch of re-queries. Cookies don't have that problem, they're always sent. At least, that's what I saw on the intranet site I built, switched to authenticating with a login page and cookies instead because of it.
greenagain 18y ago
"Some Web frameworks use session state to track and hold information about the user throughout their journey through the site, however they go against the RESTful principles and should really be treated as a bug." I'll bet this guy's not fun to be in design meetings with.
nuclear_eclipse 18y ago
How do you prevent against CSRF attacks (http://en.wikipedia.org/wiki/Cross-site_request_forgery http://en.wikipedia.org/wiki/Cross-site_request_forgery) if you don't maintain any state server-side? The classic (and best) method for foiling these attacks is to store a special/randomized token in a server-side session, and require that token to be submitted from the client via a standard form, essentially making forged attacks impossible. Take away the ability to store these tokens in some sort of server-side session, and you open your site to attack?
- sfg 18y ago
  In his example, where the server maintains the state of the basket, all the requests from the user require a user name and password which will be used to authenticate the user and thus prevent identity forging.
- JulianMorrison 18y ago
  Give a ticket with each response, require a ticket with each request. Tickets are signed with HMAC, dated, and individualized to the user login. Creating a ticket, the server forgets it. Receiving a ticket, the server checks it, creates another, and forgets that.
  - nuclear_eclipse 18y ago
    I don't quite understand how the server would validate the ticket if it's been forgotten. Wouldn't that just allow any forged request to generate a seemingly valid ticket and submit a request like that. Further, excuse my ignorance, but can you explain how HMAC would help in a more user-friendly language than what Wikipedia provides?
    - run4yourlives 18y ago
      From one of the articles linked in the wiki entry: Basically it’s done like this: 1. The server passes a random string to the client 2. The client performs a calculation on the password and the random string 3. The client passes the username (in plain text) and the result of the calculation to the server 4. The server performs the same calculation as the client did and compares the output to the output of the client. 5. If it’s a match, the client is authentic.
run4yourlives 18y ago
I'm in full agreement with him within the frames of the shopping cart analogy/function. I'm trying to think though, of things I currently use a session state for that would suffer under this process. The cart on client scares me when it has to do with data that isn't trivial. (ie, personal data etc) I don't have these concerns with the "cart on the server" idea, but it does create some interesting issues where devs need to be explicitly aware of who is accessing this data at any given time.
- newt0311 18y ago
  No kidding. Preventing forgery would be a nightmare.
  - jgrahamc 18y ago
    No it isn't. You just sign the data that's on the client and check the signature when it is returned. See http://news.ycombinator.com/item?id=325551 http://news.ycombinator.com/item?id=325551.
jwilliams 18y ago
I read this and thought - why not just use sessions? His client example is riddled with security and integrity issues. People don't like accidentally closing a tab and losing everything. His server example is just another way of doing sessions.
- snorkel 18y ago
  Also the user loses their entire state if they switch web browsers or sit down at a different terminal. Granted they'd have to log back into your site to restore their state but at least there's something there to be restored.
njharman 18y ago
What if you need state for users without username and password? For instance let them add things to their cart and only require registraton/login once they buy. What if you want more than one basket? What if baskets are shared among users. Replace "basket" with "state" for above. How is http://example.org/shop/users/johndoe/basket http://example.org/shop/users/johndoe/basket different/better than http://example.org/shop/users/johndoe/?sessionkey=123456 http://example.org/shop/users/johndoe/?sessionkey=123456 or http://example.org/shop/baskets/123456/ http://example.org/shop/baskets/123456/ "differ from storing the cart in a user session" I never store anything but sessions in user sessions, carts go in the cart table/whatever. Carts may have a session_id they are associated with, but they are probably keyed to user instead(depends). Probably stored in a cookie(state on the client). Not saying author is wrong, I just don't get it. And how come rest folks don't end their resources with a '/'. like http://example.com/users/bob/ http://example.com/users/bob/ The "root" resource ends in a slash. http://example.com/ http://example.com/ Having that be inconsistent with other resources always bugs me. I tend to have verbs not end in slash. http://example.com/users/bob/delete http://example.com/users/bob/delete Very consistent and orderly to my obcom mind.
jgrahamc 18y ago
Old, old, old idea. Even I was writing about this in 2006. http://www.jgc.org/blog/2006/04/stateless-web-pages-with-hashes.html http://www.jgc.org/blog/2006/04/stateless-web-pages-with-has... When I wrote that Matt Sergeant posted that this idea had been around since at least 1999.

26 points by rams 18y ago

an interesting read but one thing I didn't understand, how is one meant to save the plaintext username & password client side (so as to be able to send them with each request) without putting them in a cookie or requiring that the user's browser is set to 'remember this password' - anyone got any ideas?

mtts 18y ago
I think the point is not that no session state at all should be stored client side, but that most session state should not be.
- alan 18y ago
  Actually, Peej is a REST fan. He's saying that if there's session state it should be on the client side. There should be none on the server side.
shutter 18y ago
That's authentication/authorization info; it should/must be stored on the client.
DougBTX 18y ago
In theory by using a cookie which can be verified by any server, but which can only be generated with the user's password (which is never stored in clear text). There is an article here, http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/ http://www.lightbluetouchpaper.org/2008/05/16/hardened-state... but the PDF link seems dead.
briansmith 18y ago
Browsers have that functionality built in as long as you are using RFC 2617 authentication.
- newt0311 18y ago
  In theory. What about in practice?
  - eggnet 18y ago
    In my experience, the browser doesn't reliably send the username and password with each request so you get a bunch of re-queries. Cookies don't have that problem, they're always sent. At least, that's what I saw on the intranet site I built, switched to authenticating with a login page and cookies instead because of it.

greenagain 18y ago

"Some Web frameworks use session state to track and hold information about the user throughout their journey through the site, however they go against the RESTful principles and should really be treated as a bug." I'll bet this guy's not fun to be in design meetings with.

nuclear_eclipse 18y ago

How do you prevent against CSRF attacks (http://en.wikipedia.org/wiki/Cross-site_request_forgery http://en.wikipedia.org/wiki/Cross-site_request_forgery) if you don't maintain any state server-side? The classic (and best) method for foiling these attacks is to store a special/randomized token in a server-side session, and require that token to be submitted from the client via a standard form, essentially making forged attacks impossible. Take away the ability to store these tokens in some sort of server-side session, and you open your site to attack?

sfg 18y ago
In his example, where the server maintains the state of the basket, all the requests from the user require a user name and password which will be used to authenticate the user and thus prevent identity forging.
JulianMorrison 18y ago
Give a ticket with each response, require a ticket with each request. Tickets are signed with HMAC, dated, and individualized to the user login. Creating a ticket, the server forgets it. Receiving a ticket, the server checks it, creates another, and forgets that.
- nuclear_eclipse 18y ago
  I don't quite understand how the server would validate the ticket if it's been forgotten. Wouldn't that just allow any forged request to generate a seemingly valid ticket and submit a request like that. Further, excuse my ignorance, but can you explain how HMAC would help in a more user-friendly language than what Wikipedia provides?
  - run4yourlives 18y ago
    From one of the articles linked in the wiki entry: Basically it’s done like this: 1. The server passes a random string to the client 2. The client performs a calculation on the password and the random string 3. The client passes the username (in plain text) and the result of the calculation to the server 4. The server performs the same calculation as the client did and compares the output to the output of the client. 5. If it’s a match, the client is authentic.

run4yourlives 18y ago

I'm in full agreement with him within the frames of the shopping cart analogy/function. I'm trying to think though, of things I currently use a session state for that would suffer under this process. The cart on client scares me when it has to do with data that isn't trivial. (ie, personal data etc) I don't have these concerns with the "cart on the server" idea, but it does create some interesting issues where devs need to be explicitly aware of who is accessing this data at any given time.

newt0311 18y ago
No kidding. Preventing forgery would be a nightmare.
- jgrahamc 18y ago
  No it isn't. You just sign the data that's on the client and check the signature when it is returned. See http://news.ycombinator.com/item?id=325551 http://news.ycombinator.com/item?id=325551.

jwilliams 18y ago

I read this and thought - why not just use sessions? His client example is riddled with security and integrity issues. People don't like accidentally closing a tab and losing everything. His server example is just another way of doing sessions.

snorkel 18y ago
Also the user loses their entire state if they switch web browsers or sit down at a different terminal. Granted they'd have to log back into your site to restore their state but at least there's something there to be restored.

njharman 18y ago

What if you need state for users without username and password? For instance let them add things to their cart and only require registraton/login once they buy. What if you want more than one basket? What if baskets are shared among users. Replace "basket" with "state" for above. How is http://example.org/shop/users/johndoe/basket http://example.org/shop/users/johndoe/basket different/better than http://example.org/shop/users/johndoe/?sessionkey=123456 http://example.org/shop/users/johndoe/?sessionkey=123456 or http://example.org/shop/baskets/123456/ http://example.org/shop/baskets/123456/ "differ from storing the cart in a user session" I never store anything but sessions in user sessions, carts go in the cart table/whatever. Carts may have a session_id they are associated with, but they are probably keyed to user instead(depends). Probably stored in a cookie(state on the client). Not saying author is wrong, I just don't get it. And how come rest folks don't end their resources with a '/'. like http://example.com/users/bob/ http://example.com/users/bob/ The "root" resource ends in a slash. http://example.com/ http://example.com/ Having that be inconsistent with other resources always bugs me. I tend to have verbs not end in slash. http://example.com/users/bob/delete http://example.com/users/bob/delete Very consistent and orderly to my obcom mind.

jgrahamc 18y ago

Old, old, old idea. Even I was writing about this in 2006. http://www.jgc.org/blog/2006/04/stateless-web-pages-with-hashes.html http://www.jgc.org/blog/2006/04/stateless-web-pages-with-has... When I wrote that Matt Sergeant posted that this idea had been around since at least 1999.