# Cookie-based session store - can it get you in trouble? **URL:** \ **Category:** Rails\ **Created:** [March 15, 2008, 7:53pm UTC](https://www.ruby-forum.com/t/cookie-based-session-store-can-it-get-you-in-trouble/132040 "2008-03-15T19:53:30Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [March 15, 2008, 7:53pm UTC](https://www.ruby-forum.com/t/cookie-based-session-store-can-it-get-you-in-trouble/132040/1 "2008-03-15T19:53:30Z")
All, I recently moved to Rails 2.0 on one of my projects, and was surprised and interested to find out that the new session store is client cookie-based. I’m skeptical about DHH’s claim that it will be “zero maintenance.” I have definitely run into bugs/mistakes that I’ve introduced into my app. where some piece of pre-existing session data causes an unwanted/unintended effect after a change. Usually, these issues resolve themselves, but in some infrequent cases, the easiest method of fixing it is to shut down the app., clear out some session data, and restart, ensuring that no problematic “old” session data is present. Obviously, this kind of recovery won’t be very easy if the session data is client-side. I have a few questions: 1. Has anyone considered this as an issue with the client - side session cache approach? 2. Has anyone created a special action that might force the cleanup of a session, in order to handle cases where cleaning the session might be necessary? 3. Also, it just occurred to me that I don’t quite understand the claim that this method is “a lot faster than traditional session stores.” So, now, instead of storing the session data on the same server and retrieving it over a high-speed network, the session data gets transmitted on each request/response as a cookie? How is that faster? Any thoughtful responses are appreciated. Thanks, Wes ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [March 15, 2008, 8:10pm UTC](https://www.ruby-forum.com/t/cookie-based-session-store-can-it-get-you-in-trouble/132040/2 "2008-03-15T20:10:12Z")
On 15 Mar 2008, at 19:53, Wes G. wrote: > 1. Also, it just occurred to me that I don’t quite understand the > claim > that this method is “a lot faster than traditional session stores.” > So, now, instead of storing the session data on the same server and > retrieving it over a high-speed network, the session data gets > transmitted on each request/response as a cookie? How is that faster? Because if you use the session for what it’s supposed to be used (i.e. as little as possible, a user id and a flash should suffice), the total length of all session data probably won’t even surpass the hashed value in the cookie that is used with serverside stores. Best regards Peter De Berdt ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [March 15, 2008, 9:11pm UTC](https://www.ruby-forum.com/t/cookie-based-session-store-can-it-get-you-in-trouble/132040/3 "2008-03-15T21:11:34Z")
Wes G. wrote: > 1. Has anyone considered this as an issue with the client - side session > cache approach? > > 2. Has anyone created a special action that might force the cleanup of a > session, in order to handle cases where cleaning the session might be > necessary? If you change the secret used for the cookie store that will invalidate all sessions. > 1. Also, it just occurred to me that I don’t quite understand the claim > that this method is “a lot faster than traditional session stores.” > So, now, instead of storing the session data on the same server and > retrieving it over a high-speed network, the session data gets > transmitted on each request/response as a cookie? How is that faster? With all the other stores, the rails process has to do something to get the session data, whether it’s open a file, query the database or talk to a memcached server. That’s going to take soe time. Not much, but it all adds up. With the cookie store, the session data just arrives with the request. Sure it’s an extra couple of hundred bytes on each request but I rather suspect that it doesn’t make a huge amount of difference, as the problem here is more likely to be the latencies involved rather than the time it actually takes to move the data (which, as Peter said, is typically small) Fred ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [March 15, 2008, 11:24pm UTC](https://www.ruby-forum.com/t/cookie-based-session-store-can-it-get-you-in-trouble/132040/4 "2008-03-15T23:24:45Z")
> Because if you use the session for what it’s supposed to be used (i.e. > as little as possible, a user id and a flash should suffice), the > total length of all session data probably won’t even surpass the > hashed value in the cookie that is used with serverside stores. I agree wholeheartedly with the sentiment about “using the session for what it’s supposed to be used for,” but I have to say that maybe it’s just me, but I come up against requirements in my app. all the time that require cross-request, non-persitent storage of state. Which is not to say that I’m into abusing the session, but it tends to be a little less trivial than just a user\_id and a flash. Wes