Rails / Sessions

Contents 1 How to change the session ID 2 Comparison of different session containers/interfaces/storage mechanisms 3 Cookie-less sessions: How to make sessions work if cookies are blocked? 3.1 Arguments that it's okay to require users to use (session) cookies

How to change the session ID

ActionController::Base.session_options[:session_key] = 'app_name_session_id'

Why? "It’s a good idea to change the session cookie’s key to prevent conflicts with other Ruby apps from the same server. Otherwise, they all try to use a cookie called ”_session_id” and thus only one application will work properly at a time from any particular Web browser." [1]

Comparison of different session containers/interfaces/storage mechanisms

PStore, ActiveRecordStore, etc.

http://scott.elitists.net/sessions.html

http://errtheblog.com/post/24

http://glu.ttono.us/articles/2006/06/23/stefen-kaes-optimizing-rails

• In Memory
  • Fastest but you lose all sessions on server crash/restart. Restricted to 1 app. Doesn’t scale.
• File System.
  • Easy setup, one file for each session. Scales by using NFS or NAS (beware 10k active sessions!). Slower than
• Database/ActiveRecordStore
  • Easy setup (comes with Rails distribution). Much slower than
• Database/SQLSessionStore
  • Uses ARStore
  • More info at http://railsexpress.de/blog/articles/2005/12/19/roll-your-own-sql-session-store
• memcached
  • Slightly faster than SQLSessionStore. Presumably scales best. Very tunable. Automatic session cleaning. Harder to obtain statistics, setup
• DrbStore
  • Can be used on platforms where memcached is not available.

Cookie-less sessions: How to make sessions work if cookies are blocked?

See also: Rails plugins and libraries, including the one developed at QS

http://lists.rubyonrails.org/pipermail/rails/2005-January/001361.html

http://wrath.rubyonrails.org/pipermail/rails/2005-March/003876.html

http://www.troubleshooters.com/codecorn/ruby/rails/rapidlearning_rails.htm :

By far the toughest part of web programming is that the HTTP protocol, which is the protocol used by the web, is stateless. That means that every web page starts knowing nothing of web pages that came before it. Programs cannot be written under such circumstances.

For that reason, programmers from the dawn of time have found various ways to pass information between web pages:

• Passing info in the URL
• Passing info in form variables
• Passing info in cookies

All persistence kludges, and that's what they are, kludges to compensate for HTTP statelessness, are ugly, and every single page on the website must pass state info, even if such pages have no dynamic content, or else state is lost. URL passing is a horrible security faux pax. Passing in form variables means every single page on the website must pass state info, even if such pages have no dynamic content, or else state is lost. Passing in cookies has privacy implications, and some people turn off cookies on their browser.

The best a framework can do for you is to shield you, the application programmer, from the drudgery of maintaining state. Rails does this with a hash like structure called session. This hash like structure is your abstraction for cookies-based state maintenance. That's right -- Rails won't work if the browser has cookies turned off -- you need to warn the user to turn on cookies before proceeding to dynamic pages that need state.

http://comments.gmane.org/gmane.comp.lang.ruby.rails/26374 Jens-Christian Fischer | 22 Oct 13:15

I worked on a game for mobile phones last year in rails and had to use url-based session management. It's certainly feasible [...]

In your views:

Add the session_id to every link like this:

link_to "somewhere", { ..., :params => { "_session_id" =>  
 <at> session.session_id }}

and in your forms, add a hidden field to carry the session id like this:

<input name="_session_id" type="hidden" value="<%=  
 <at> session.session_id %>"/>

that's basically all there is to it. It would be nice, if this could be auto-generated by rails, but I haven't gotten around to investigate this further.

http://comments.gmane.org/gmane.comp.lang.ruby.rails/26374 Robert | 22 Oct 21:50

class ActionController::Base
   def default_url_options(options)
     { '_session_id' => session.session_id }
   end
end

But here again bug #210 strikes back. Rails doesn't seem to "absorb" the _session_id param when POSTing. So you can't do:

<form action="/some_controller/some_action?_session_id=XXXXX">

Just doesn't work (at least for me, when I tested it).

(also mentioned here: http://one.textdrive.com/pipermail/rails/2005-January/001415.html / http://lists.rubyonrails.org/pipermail/rails/2005-January/001361.html)

(bug mentioned at http://dev.rubyonrails.com/ticket/210)

So the default_url_options thing works for all url_for-based URLs, but doesn't help with redirect_to or forms (which use POST).

http://www.freeonrails.com/node/12798 Bob Norfolk on September 29, 2006 - 7:03pm.

You can override url_for and form_tag in application_helper.rb.

One potential danger with allowing session IDs to be passed in the URL is that it opens us up to impersonation attacks. (See, for example, the section on Impersonation at http://shiflett.org/articles/the-truth-about-sessions .)

Arguments that it's okay to require users to use (session) cookies

http://lists.rubyonrails.org/pipermail/rails/2005-January/001415.html

I agree that for online shopping, sessions encoded in the URL is a security issue waiting to happen. But for some apps using cookies also isn't an option because of browser limitations (e.g. most mobile browsers). So it would be nice to have this option available

http://www.freeonrails.com/node/12798 Bob Norfolk on September 30, 2006 - 3:56am:

As to whether Rails "is simply not usable for professional development" - there's a lot of evidence to refute that. 37Signals is making a boatload of money- you think they're not "professional"? If so, I have to say, that's the kind of non-professionalism I aspire to ;-)

Having said that, I think support for session-id-in-url would be a great addition to Rails- as DHH might say, "please do write a plugin" ;-)

Lastly, much of this talk about people having cookies disabled misses a fine distinction. The cookie that Rails uses for session id expires when you close your browser. While some people may have persistent cookies disabled, I would venture to guess that the number that have non-persistent (session) cookies disabled is considerably less. As Eric Knapp points out, above, much of the modern web would be practically unusable without session cookies. Ever used a shopping cart?

Over at Lingr (http://www.lingr.com), we haven't heard any feedback from users complaining about our requirement of session cookies. I doubt we ever will. I'm certainly not loosing any sleep over whatever users, if any, we turn away due to that requirement.

http://www.freeonrails.com/node/12798 snacktime on September 29, 2006 - 7:17pm:

Without a way to make sessions work with the id passed in the query string, it will limit rails in some areas, although how many I don't know. I do know that many ecommerce sites need to work without cookies, especially those that have mobile phone friendly pages. We have a fairly large ecommerce app written in perl being used by a lot of merchants, and the number of people who block cookies is small, but significant enough that we don't require cookies.

http://one.textdrive.com/pipermail/rails/2005-January/001412.html On 03/01/2005, at 2:31 PM, Tobias Luetke

Well, from a business point of view, your client might say "it's too dangerous to only rely on cookies, because I'll lose sales", which is fair enough.

PHP's trans-sid stuff is pretty good at deciding if a link or form needs to have the session ID appended, and the url_form link_to etc functions could surely be extended to take care of this automatically.