What's New in Edge Rails: Cookie Based Sessions are the New Default

Posted by ryan
at 11:15 AM on Wednesday, February 21, 2007

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:


Update: Feb, 22nd 2007

To get your brand new cookie-based session up and running, make sure this bit is in your environment.rb:

config.action_controller.session = { 
  :session_key => '_my_app_session', 
  :secret      => 'some_really_long_and_hashed_key' 

tags: rubyonrails, rails


Leave a response

  1. PikuFebruary 21, 2007 @ 12:11 PM

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

  2. Dick DaviesFebruary 21, 2007 @ 12:29 PM

    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.

  3. Dick DaviesFebruary 21, 2007 @ 12:39 PM

    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 :)

  4. MasterLeepFebruary 21, 2007 @ 12:45 PM

    How is the cookie scoped? If it adds overhead to every URL request, that seems like it could be an issue for client bandwidth.

  5. IanZFebruary 21, 2007 @ 05:07 PM

    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?

  6. Ryan DaigleFebruary 21, 2007 @ 07:56 PM

    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.

  7. Duncan BeeversFebruary 21, 2007 @ 08:08 PM

    IanZ: Cookies can be set by a redirect.

  8. Steve EhrenbergFebruary 21, 2007 @ 09:14 PM

    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?

  9. court3nayFebruary 21, 2007 @ 09:34 PM

    For a more in-depth look, http://blog.caboo.se/articles/2007/2/21/new-controversial-default-rails-session-storage-cookies

  10. Chad HumphriesFebruary 21, 2007 @ 10:24 PM

    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…

  11. Ryan DaigleFebruary 22, 2007 @ 08:51 AM

    @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).

  12. RailsNoobFebruary 22, 2007 @ 03:22 PM

    Why not include salt by default to protect the secret key from chosen-payload and dictionary attacks?

  13. Bryan Field-ElliotFebruary 23, 2007 @ 12:35 PM

    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?

  14. Keith LancasterMarch 01, 2007 @ 02:56 PM

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

  15. SergeyMarch 06, 2007 @ 07:22 AM

    There are only one issue. Logout not works in general scenario 1. reset_session 2. redirect

  16. ZiaMay 28, 2007 @ 10:21 AM

    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?