Rails core - Jul 2008 - 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??
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

On Jul 29, 3:56 pm, "Michael Koziarski" <mich...@koziarski.com>
wrote:
> > 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.
>
>
>
> > 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.
>
> > On Jul 28, 4:49 am, "Michael Koziarski"
<mich...@koziarski.com> wrote:
> >> > 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?
>
> >> > 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??
>
> >> --
> >> Cheers
>
> >> Koz
>
> --
> Cheers
>
> Koz
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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


-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---