Cookie-based session store - can it get you in trouble?

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

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

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

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?

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

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