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.
2
1
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
Tempting to use authenticated encryption for client-side state and it seems super clean and simple until you really start thinking about all the things that could go wrong and the lack of oversight over state.
Another example: recovering from server time being set incorrectly.
Client-side login sessions and other similar state is what I was taught to do when I was an inexperienced developer. It was made out to be super modern and clean while totally glossing over what's wrong with it.
The very complex common standards/libraries for it are a bit scary.
1
1
As another example: user logs out in their browser but then restores from a backup. They should still be logged out, but they won't be with client-side sessions. Same applies to other things.
Not really avoiding a database but rather using a highly unreliable distributed one.
1