Comments on: Cookies and sessions in Rails 2.0

By: madpilot

madpilot — Sat, 02 Feb 2008 01:32:25 +0000

Sorry about the formatting there, Looks like you can’t use pre tags or br tags in comments…

By: madpilot

madpilot — Sat, 02 Feb 2008 01:26:22 +0000

Hi Eric, I've never had any problems with curl and sessions (cookie-based ones or otherwise), how ever, if you wanted to turn them off completely create a file called no_store.rb in the lib/ directory and drop this code in there:


require 'cgi'
require 'cgi/session'

class CGI::Session::NoStore
    def initialize(session, options = {}); end

    def restore
        {}
    end

    def update; end
    def close; end
    def delete; end
end

then add this to you environment.rb file (Near commented out line about active_record_store):


require 'no_store'
config.action_controller.session_store = :no_store

This is effectively a session store that does nothing, so technically cookies are still turned on, but they are disabled. Hope that helps.

By: Eric Larson

Eric Larson — Fri, 01 Feb 2008 17:41:33 +0000

I am wondering how turn this off as well, as programmable clients or curl don’t easily work with the cookie bits. I’m writing a service that won’t be used by a browser and won’t use any cookies.

By: m1ke

m1ke — Thu, 27 Dec 2007 16:21:15 +0000

Is there a way of having rails NOT storing 127 chars for a session ID? Sure, security is one thing, but let’s assume that guessing 127 chars is pretty difficult for most rails apps out there.

By: madpilot

madpilot — Sat, 22 Dec 2007 00:10:45 +0000

Hi Don,

I stand corrected on that comment - I just went through the source code, and you you are right - it is just a base64 encoded version of a Marshalled object with a hashed digest that you can compare against.

As I said before - if you have any info in there that you didn’t want sniffed, use one of the other stores.

By: Don Park

Don Park — Fri, 21 Dec 2007 21:56:03 +0000

“First of all, let me point out that the the store isn’t stored in plain text - there is a new forgery key in the environment.rb file”

a SHA is a one-way hash. the session is stored in the cookie in plain text along with the hash. any tampered-with session data is rejected, but the data itself is in plain view. (note i havent used cookie session store myself, this info comes from my reading on the topic)

By: madpilot

madpilot — Fri, 07 Dec 2007 01:01:14 +0000

wwb_99: Yes, this is a good point, although some may argue that if you are keeping that much data in the session, perhaps you should reconsider your flow. Having said that, if you do need to store a large amount of data in a session PStore probably isn’t a good bet either, so you would be using one of the other solutions anyway.

Philippe: There has been a push on the core-dev list for a generator rake task - if that makes it through, there is no real reason to USE the default value. I’m of the opinion that you should generate your own key for each application.

By: Philippe Rathe

Philippe Rathe — Thu, 06 Dec 2007 15:56:17 +0000

Well as of today (december 5 2007), edge Rails generates a 127 bytes secret for the session.That’s long. One week ago, edge rails was generating a 32 bytes secret.

My question is : Should we rely on the Rails generator for production if we choose CookieStore? Even if the generator seems good, it’s still public.

By: wwb_99

wwb_99 — Wed, 05 Dec 2007 13:46:28 +0000

Outside of the security issue, I can see another huge one–all your session variables got alot more expensive. A big part of the reason that people moved to sessions and away from cookies was that all that data was not pushed down to the client and back but rather remained on the server. So, depending on what you are keeping in the session, it could easily clobber your site.