There is another way of making your web application stateless: encrypting the state and telling the client to hold on to it for you.
That approach has risks. twitter.com/isotopp/status
This Tweet is unavailable.
3
1
20
Conversation
Replying to
Do you have resources on the risks? Want to make sure I don't miss something
2
2
Pervasive example:
Client-side sessions via signed tokens prevent providing a list of active sessions with details and the ability to end them. It's useful for both the user and administrators to have them in the database. It feels cleaner to not track it properly but it isn't.
at least an "end all active sessions" is possible with a counter
but the list of active sessions is of course better, yes
1
1
Even having only a counter for each account is essentially giving up on doing it client-side.
What if the database has to be rolled back to a backup?
Do you rotate the key and invalidate client-side state entirely?
It's a problematic approach overall, I think. Not a fan.
1
1
Show replies
For the Twitter site, as an example:
Settings → Security and account access → Apps and sessions → Sessions
If simply simply signed a user id + date pair with a key, they couldn't provide this. This tends to be where sites start going wrong. Next is a shopping cart, etc...
1