#84
Dec 17

Cookie Based Session Store

In Rails 1.2 the default session store is file based. This is inefficient and difficult to maintain. In Rails 2.0 the default is now cookie based which has several benefits as you will see in this episode.
Tags: rails-2.0
Download (4.9 MB, 4:00)
alternative download for iPod & Apple TV (4.6 MB, 4:00)
Resources
# in environment.rb
Rails::Initializer.run do |config|
  config.action_controller.session = {
    :session_key => '_store_session',
    :secret      => '851939c37d94574e284ded8437d4ea3447dae24cc5bda61d8eaf2731d49273bc4c620'
  }
end

13 comments:

Olli Dec 17, 2007 at 05:05

Thanx for the good start into the week :D


Neeraj Dec 17, 2007 at 06:52

If you are migrating from Rails 1.2 then you can use this rake task to generate the secret key.
rake secret:generate:key More info at
http://dev.rubyonrails.org/ticket/10363


NoobSaibot Dec 17, 2007 at 07:33

i wonder why it is not possible to create a submit button by writing something like: f.submit

This makes it kinda difficult to create custom form builder.

Do you have any hints on that issue?


robert Dec 17, 2007 at 08:15

Neeraj: It's actually been changed to rake secret. I originally had it as that long winded rake task but after talking to bitsweat and DHH, it got shorten down to rake secret.


Grant Dec 17, 2007 at 08:56

I know people aren't crazy about MS's View State, but is there a way in Rails to write session state to the rendered html. I have users that do not want to use cookies.


R. Elliott Mason Dec 17, 2007 at 13:52

I didn't know Rails 2.0 had this.

I remember when it was impossible for me to open or even delete the sessions folder on my server because it was filled with thousands of files. Ended up using some shell command that I can't recall, and even then it took a few minutes to complete.


Mr Bogus Dec 17, 2007 at 20:43

You didn't mention this, but I assume the encrypted cookie approach also has an added overhead of session data encryption and decryption. Perhaps a good use for memcached.


Stephen Dec 18, 2007 at 02:17

If one of your goals is to use obfuscated URLs to hide the IDs of users and other objects, doesn't storing the ID of the user in the cookie screw things up for you? I guess unless you store the encrypted ID...


M Graff Dec 18, 2007 at 09:05

If you are using secret ID numbers, you should really evaluate why you are doing this. Is there harm in letting the user see that an object is number 1001, and is that different than seeing an encrypted id of 10230103103, if both are constants?


Mike Dec 18, 2007 at 15:09

I am using SQLSessionStore plugin (wich was proven to be far more faster the the default file method and even the activercrd session method). Is it smart to switch over to the new cookie method?


Ryan Bates Dec 18, 2007 at 16:05

@NoobSaibot, I hope to cover custom form builders in a future episode. Thanks for the suggestion!

@Mr Bogus, I haven't done any performance testing on this yet so I'm not really sure of the overhead.

@Mike, if you already have a working solution that doesn't cause problems or constant maintenance then I would say stick with it. The biggest benefit I see to a cookie based store is the zero maintenance.


cease Dec 21, 2007 at 11:20

on a side note.. why don't these mov files play in vlc ? I hate quicktime


Tony Dec 30, 2007 at 01:12

What if the user has multiple browser windows open to the site? Are they now sharing the same session information, even though they should be considered two different sessions?

Add your comment:

(required)

(not displayed)

(SKIP THIS ONE)


(required)

subscribe:
sponsored by:
if you want to help:
required:
Get Quicktime Player