Earlier quoted context omitted.
Wasn't that Vizzini?
It was Vizzini who kept using that word, and Montoya who did not think it meant what he (Vizzini) thought it meant.
Rails' CookieStore isn't broken
31–33 of 33 posts
Re: Rails' CookieStore isn't broken
#32If you're going to store info about sessions in the database and thus have to query the database on every request to make sure the cookie-delivered session is okay... why wouldn't you just use the ActiveRecord session store instead of the cookie store? What do you gain by using the cookie store with this database component, over just using the active record store to begin with? (The ActiveRecord store used to be the…
I think it's still worthwhile to use CookieStore even if you're going to go to the DB, because:
1. You only do DB round-trips for cookies that contain a valid user ID, and you're going to be pulling that user record anyway, so the net effect is a few extra bytes over the wire on DB work you were going to be doing anyway. Critically, this means that anonymous users aren't going to be generating sessions that you have to store and validate on every page with a form (as forms use csrf_token which generates a session!)
2. Additionally, less data over the wire between the app and DB. You're going to have a small list of active sessions; you could enforce that as a to a small number to ensure it stays small.
3. You retain CookieStore's invulnerability to session fixation.
4. No sweeping!
You can still put most of the work on the client, and only keep the verification bits on the server. Of course, the same technique is applicable to DB-backed stores as well, as a means to provide a mechanism for users to manage their sessions.
Re: Rails' CookieStore isn't broken
#33I don't think requiring that your user(s) be compromised before this becoming an issue is a valid defence. Especially when cookies are easily stolen using something like Firesheep or as simple as forgetting to logout of a public terminal. You should ultimately be putting in systems that, if in the event of a compromise, you can mitigate the cost to the user.
Completely agreed - that's the gist of the DB bits there. Right now, you can terminate a compromised AR-backed session by logging out, but if you lose that session ID, then you have no control over the compromised session. If someone jacks your SID while you're on a public terminal, using ARStore alone isn't going to save you.