The question is, how does Rails deal with session when the user’s browser does not accept cookies? In a J2EE app, the app server does URL rewriting to attach a session id to the URL. Does Rails do anything similar?
I’d love to see a patch for this—companies in the security software business have done a great job of scaring people away from cookies, it’s a major hassle but we have to deal with it. —GreasyP?
try Hidden Field Session Plugin.
Well, the wisdom on IRC is that you need to require cookies.
e.g. ror.log.20041120:
nextangle jcfischer: You can pass the session id around every where. But it’s quite a pain. Why don’t you want to require cookies?(You can’t use Basecamp if you don’t use cookies)
I think they’re right, but I’m still going to write the patch. —p13d
2008-03-18 – encoding session id in the URL can be quite painless and there is a Plugin written specifically for this purpose. A write up is available here: Rails No-Cookie Session Support Plugin
You are welcome to use the code in the patch if it will be of use.
—Long
There is at least one legitimate reason for not wanting cookies: some people (me for example) do not want to be tracked across multiple web pages by advertisers. I refuse to use web pages (bank sites excluded) that take the easy way out and require cookies. [Totally ignoring the fact that you can also be tracked with their logs.] (Totally ignoring the fact that cookies are persistent with most advertising sites setting an expiration date 100 years from now. With an IP address, companies have to assume that it changes (as most home internet connections have dynamically allocated addresses) making it more privacy friendly.)
Simple web browsers on some cell phones don’t even seem to support cookies, so in the case of my app I’ve simplified what was going to be stored in the session, and passed around the few remaining variables as URL parameters. —Dan W.
There is at least one other reason against cookies (for session-ids). They are affected by an almost unknown vulnerability, called “Session Riding”. So please consider at least an optional GET based mode. —Patrick Gupta
Why Session Riding isn’t worth mentioning
Session riding is irrelevant. The attacker has to be sure that:- The site uses persistant cookies
- The user is a user of the site in question AND has a cookie that is active
- The user is stupid enough to click a link that says: http://domain.com/?cmd=make_bid&amount=500
- Okay I know that many people still fall for this kind of stuff, but they aren’t the people who turn cookies off.
And if you think this risk is enough to still warrant even reading my words, there are easier ways to get around it:
- Disable persistant cookies
- If you want persistant cookies, have a separate authentication domain (login.domain.com)
- This means you can set a peristant cookie for that domain only and a cookie that expires for *.domain.com.
- When the user is redirected to the login domain, a session cookie can be set.
- As a user clear your cookies on exit, firefox can do this automagically.
-Simon Wex
People who are 100% against cookies also wear foil hats. It’s also quite easy to selectively block specific cookies with browsers like Firefox. There’s also a security risk with having URLs with sessions IDs in them, which nobody has mentioned.
The point here is that this is supposed to be a howto on maintaining sessions without cookies, not a howto on telling someone what they can’t do.
How would one go about detecting if cookies are enabled? My authentication scheme dies hard if the remote browser has cookies disabled (something I should fix anyway), but I’d still like to be able to detect the absence of cookies and give an informative error message.
One mitigating factor not mentioned in the link above is Referer-verification. Do any of the Authentication frameworks actually support defining the allowed source urls/actions for each action to be performed?
We shouldn’t disregard security concerns- granted for a blog or someother non-profit site this will not matter, but if RoR wants to go big time it makes sense to have a non-cookie session helper that can maintain some state variables within hidden encrypted fields. Keep in mind that cookies can also be forged and an active cookie can be easily hijacked by a smart hijacker who can detect when a user logs on to their secure site. – I consider my tin foil hat a fashion statement anyway.
I also dislike cookies, if abused (sent to other (advertising) sites, embedding more information than neccessary etc.). BUT, rewritten GET URLs can be quite as bad from a security POV. There is no silver bullet to this, http is a sessionless protocol. For absolute tight security, users would have to authenticate for every single request, aka no sessions at all, or use one of http’s own authentication methods (basic auth. over SSL anyone?). Try to sell that.
Just because some security shills try to sell you on anti-cookie products, that doesn’t mean there is something better if used responsibly. A real evil guy could sell his clickstream logs anyway.
-Jügen Strobel
People, have you forgotten that not every single internet-enabled device supports cookies ?
Right now I’m working on a mobile phone only site and the terminals I’ve got to deal with DO NOT play nice with cookies at all…
So please, think twice before writing statements like “you should enforce the use” because in some cases it is simply NOT possible