What's New in Edge Rails: Cookie Based Sessions are the New Default
Edge rails now has cookie-based session stores enabled by default instead of the file based session store that was the previous default. Why the change? Mostly performance, it seems. Cookie-based sessions are just faster to retrieve and process than hitting the file-system on every request. Plus, I would imagine they scale considerably better as they’re persisted on the client side and have no server-side persistence requirements.
The caveat? Cookies are generally limited to 4K in size. While not an issue for most (proper) usage of the session, this could be a legitimate limit for some scenarios. If your app abuses the session so, you’ll need to decide on a different session store. Your other options are, of course:
- ActiveRecordStore
- SQLSessionStore
- DRBStore
- MemCacheStore
Resources
- Err the Blog has a great Rails session-rundown that discusses all your options.
- Scott Baron has a good, if not slightly dated session store performance comparison where you can make an informed decision about what best meets your session needs.
Update: Feb, 22nd 2007
To get your brand new cookie-based session up and running, make sure this bit is in your environment.rb:
1 2 3 4 |
config.action_controller.session = {
:session_key => '_my_app_session',
:secret => 'some_really_long_and_hashed_key'
} |
tags: rubyonrails, rails
- Tags: Edge Rails
- Meta: permalink
Comments
Leave a response
Follow me on Twitter
But that isn’t a security hole ? You have to be very careful about what you store on the client, so you can’t store the whole User model only the id (a practice used by me in PHP but now with act_as_authenticated not used).
That’s my concern too. All the other session stores keep sessions up at the server for a reason.
To make it safe, the application has to be extremely paranoid when retrieving anything from a session. Anything written for earlier versions of rails is potentially going to be caught off guard.
Looking more closely, the cookie has a SHA512 fingerprint attached and is hashed with a secret stored up on the server.
I’m less scared now :)
How is the cookie scoped? If it adds overhead to every URL request, that seems like it could be an issue for client bandwidth.
How does this work in the following scenario?
session[:var] = ‘testing’ redirect_to :action => ‘index’
Cookies cannot be set when using a redirect, AFAIK. So, doesn’t this change break a lot of code?
Or does Rails do some cool stuff to make sure that the cookie is still set in the client during/after the redirect happens?
Sorry folks, I forgot to throw in there that the cookie includes a SHA512 signature hash, ensuring no tampering with the data.
However, if there is sensitive data that you don’t want anybody seeing (not just changing) then you’re best off using a server-side store. But, most Rails apps are architected to have minimal session info, and certainly none of any importance. For those standard apps, a cookie session store will do just fine.
IanZ: Cookies can be set by a redirect.
Does this mean if I just freeze edge into my brand new app without changing anything in environment.rb, it’ll use the new cookie sessions? Or do I have to change anything to take advantage of this?
For a more in-depth look, blog.caboo.se/articles/2007/2/21/new-controversial-default-rails-session-storage-cookies
I modified acts_as_authenticated a while back to use hmac-sha1 encrypted cookie vs session for backing. I was trying out the idea because I had to revisist an old asp.net app and I noticed the formsauth.
It looks like this will take care of that though…
@Steve – yes, without doing anything in your config all edge rails apps will now have cookie-based sessions. However, make sure to update your environment file so that it sets the secret key for the cookie signature (I would throw up an example but the Rails tracs is down right now and I don’t remember the exact syntax – check the source when it’s up to see what I’m talking about).
Why not include salt by default to protect the secret key from chosen-payload and dictionary attacks?
This seems like a great option if only the cookie contents were encrypted. Can’t use it without encryption. How hard would that be to add? You’re already managing a secret key, and already signing. Why not encrypt too?
So that nobody else gets confused like I did, the example for what goes in the environment.rb file is actually from the generator (at least, that’s what Rick Olsen says…). Any variables actually need just regular string processing #{yada}, etc., not <%%>.
There are only one issue. Logout not works in general scenario 1. reset_session 2. redirect
Can any body tell how to get this cookie based session get going. I am new in rails and dont understand much. The lines given above to be added into the environment.rb file didn’t work. The mongrel server doesn’t start and displays error that session= is not found. Can any body help?