

Living Without Sessions - rams
http://www.peej.co.uk/articles/no-sessions.html

======
greenagain
"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
How do you prevent against CSRF attacks (<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?

~~~
JulianMorrison
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
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
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.

~~~
JulianMorrison
That's a HMAC password protocol, it's different.

In the case of tickets, the one signing is "this server then" and the one
checking is "this server now", with a period of amnesia (about the data, not
about the password) in between.

~~~
run4yourlives
Ahh, my bad. I think I see where you're going with this now. You're basically
just remembering the last visit a particular client makes on every request,
and then resetting the ticket for the next request correct?

~~~
JulianMorrison
Imagine a disposable photo-ID ticket marked "admit one authenticated client".
The bouncer takes it, looks at it, looks at you, tears it in half, and lets
you in. You get to make a request, and as you carry the response out of the
exit door, a member of staff takes your photo and prints a fresh ticket.

------
jwilliams
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
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.

------
jgrahamc
Old, old, old idea. Even I was writing about this in 2006.

[http://www.jgc.org/blog/2006/04/stateless-web-pages-with-
has...](http://www.jgc.org/blog/2006/04/stateless-web-pages-with-hashes.html)

When I wrote that Matt Sergeant posted that this idea had been around since at
least 1999.

------
njharman
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> different/better than
<http://example.org/shop/users/johndoe/?sessionkey=123456> or
<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/> The "root" resource ends in a slash.
<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> Very consistent and orderly to my obcom
mind.

------
run4yourlives
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
No kidding. Preventing forgery would be a nightmare.

~~~
jgrahamc
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>.

------
lisp_padawan
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
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
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.

