cookie session store does not generate a unique id

session.session_id is not unique if you are using cookie sessions.
This doesn't make sense to me. ActiveRecord cookie stores have unique
ids, as does p_store.

If you look in cookie_store.rb, you'll see that it sets:

options['no_hidden'] = true

From the looks of this, options['no_hidden'] makes CGI exclude the
session id from the cookie. So for every non-logged in user,
session_id is the same.

I'm not sure if this is a bug or not, but I certainly didn't expect
it, and it broke one of my apps when I switched from AR to cookies,
and there seems to be no documentation about it, except for the
comment right above the line in cookie_store.rb.

Does any one else think that we should keep the api to cookie stores
the same, or does adding a session_id to cookie store add too much
data for the 4K??

From the looks of this, options['no_hidden'] makes CGI exclude the
session id from the cookie. So for every non-logged in user,
session_id is the same.

Right, with cookie store the session_id is the session data itself, so
identical values will lead to identical session ids.

I'm not sure if this is a bug or not, but I certainly didn't expect
it, and it broke one of my apps when I switched from AR to cookies,
and there seems to be no documentation about it, except for the
comment right above the line in cookie_store.rb.

We could probably do with a little more documentation on the various
cookie stores and their pros and cons, I believe there's a guide on
the wishlist for that.

What were you doing with the session ids which broke?

I have a page where users can rate movies they've seen, and some may
log in after they've voted. So when a non logged-in user votes, I
grab the session_id and store it with the rating. When the user
eventually signs up, the rating is then connected to their user
account. I can easily accomplish this by adding some token to the
session, but there was never any need to before with p_store or AR,
since session_ids would suffice as a unique key for my purposes.

My tests covered the case where a user voted, then logged in, so when
I switched to cookies tests were green. But then I found a bug where
when a user registered, they inherited the votes of every other non-
logged in user that had voted. The fix is easy, and I can now write
expanded integration tests that simulate multiple users which I
arguably should have done from the start, but I try not to retest
things that are covered in rails, and I incorrectly assumed a unique
session_id to be there.

It was such a strange behavior that I spent several hours trying to
figure out where I had written some line of code that magically
assigned the same session id to every user, and had debug statements
all the way down into the ruby CGI library before I figured it out
that it was baked in.

I have a page where users can rate movies they've seen, and some may
log in after they've voted. So when a non logged-in user votes, I
grab the session_id and store it with the rating. When the user
eventually signs up, the rating is then connected to their user
account. I can easily accomplish this by adding some token to the
session, but there was never any need to before with p_store or AR,
since session_ids would suffice as a unique key for my purposes.

You could also have stored the ids of the votes themselves in the
session too right?

Have a look at what a patch would involve, perhaps it can be made an
option in session_options or something similar? Assuming it's
harmless enough and fully backwards compatible I can't see why we
wouldn't apply it.

After having a look - I'm not sure that this is worth a patch. I
think documentation is probably the better route to go here - if I
were designing a session container from the beginning, I wouldn't put
a unique id here. More than anything I was just surprised and
frustrated at the inconsistency, but better docs would have helped me
there. I'll take a look at the rails doc project and add some more
info about the various cookie stores, once I grok memcached and drb a
bit more.

After having a look - I'm not sure that this is worth a patch. I
think documentation is probably the better route to go here - if I
were designing a session container from the beginning, I wouldn't put
a unique id here. More than anything I was just surprised and
frustrated at the inconsistency, but better docs would have helped me
there. I'll take a look at the rails doc project and add some more
info about the various cookie stores, once I grok memcached and drb a
bit more.

I wouldn't worry too much about the drbstore, I'm not even sure if
anyone uses it any more, perhaps we should remove it.

Back in the day someone (scott barron maybe?) had a blog post or
article on comparing the performance characteristics and pros and cons
of each of the session stores. Perhaps you could dig that up, convert
it to a guide in docrails, then bring it up to date.