#84 Cookie Based Session Store

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

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?

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.

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.

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.

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.

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

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?

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?

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

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?

Hi, I have a question.

I'm planning to use a reverse proxy on production. When I use Firebug to watch the response headers, I see that a header of "Set-Cookie" is set with the same session id on every request.

Now, with every request from the same user, the reverse proxy will always think it is a new session and hence prevent caching and affect the performance.

Can you help me to fix this?
Thank you.

Thanks for a nice cast!

Though, from a security perspective, this somewhat scares me. I've always considered "cookies vs sessions" to be clientside-variables vs serverside-variables, where sessions were stored serverside and a cookie was used to keep track of the session id only.

Also, worth mentioning is that cookie-based sessions is of course nice if you have multiple servers serving the same content, though, for sensitive data, a database or memcached might be an option. :)

Again, thanks for another lovely case! Keep up the good work! :D

(I know this cast is old, but I am really new to Rails!)
You are saying that everything that is stored in session is encrypted. However, here, it says that

The client can see everything you store in a session, because it is stored in clear-text (actually Base64-encoded, so not encrypted)

and

There are, however, derivatives of CookieStore which encrypt the session hash, so the client cannot see it.

So, I am a little bit confused about whether a client can read the session hash or not.

BTW. While waiting for your answer, I found this.

Is there any cast on using database or memcached to store session data instead of cookie.