Forum: Ruby on Rails Why does the the cookie_string have two entries for my site?

Bb84647959d99f5abf6f2695865d06ce?d=identicon&s=25 Johnny (Guest)
on 2014-08-20 22:59
(Received via mailing list)
I'm having an issue with my Rails 3.2.19 app.
If someone is idle on our site for 20 minutes and they had items in
their
cart, then on their next request, we clear their cart, redirect them to
the
homepage and display a message telling them that their session expired.

Roughly this is what happens:

   - User clicks anywhere
   - before_filter in application_controller determine that user session
   has expired and that they had items in their cart
   - we destroy their session via `reset_session`
   - we set up a new session for them
   - we redirect them to the home page.

Now here is where things go haywire.  When the home page starts to load,
the before_filters fire again.  Now instead of evaluating the session as
recent/not expired, it is evaluated as expired again and they are
redirected again.  Now we're in an infinite redirect loop.

So, what's going on?

I figured out how to detect that an infinite loop is occurring, so I
raise
an error as soon as it starts.
Adding some logging and digging into the Exception Notifier emails I
receive I observe this:

Error raised at *14:34:43.*
Session info (logged first thing in the application_controller before
the
before_filters start manipulating it):
 {"session_id"=>"bc9dc91ac0b35af72308f0dfca92fd0c",
"_csrf_token"=>"NpDWfN3Re1MAPam6DTd00d9R8bkuowunRrSXBYQrCU=",
"updated_at"=>Wed,
20 Aug 2014 *13:48:06*}

So, the session is expired. Why?  Didn't I just create a new one?
I keep digging and see this in the exception email:
* rack.request.cookie_string:
*_myapp_session*=EnCodEdCoOkIeStRiNg1--78426612a47f5de3cc2acff7d99df6cf8395769a;
*_myapp_session*=EnCodEdCoOkIeStRiNg2
—e2ddc6d345fd3e9b91322e7194e56145ec6b5721

(I changed the strings, obviously)
There are two keys for my site!

Since this is Rails 3, I decoded both and see that the first one
contains
the old session info, and the second one contains the newer session
info.
Rails (Rack?) keeps loading up the first, older session, which is
causing
my redirect loop.  I believe this is the code responsible for loading
the
cookie
<https://github.com/rack/rack/blob/master/lib/rack/....
(env["HTTP_COOKIE"] does contain the same string as
rack.request.cookie_string, including the two keys for my app)

So, anybody have any idea why both cookies are present?

I've been searching and haven't found others with this issue.
This doesn't happen to every user.
I've been logging HTTP_USER_AGENT strings, and it's happening in IE,
Safari, and an Android browser.

Any help will be appreciated.  This is driving me crazy.
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2014-08-21 15:53
(Received via mailing list)
On Wednesday, August 20, 2014 9:57:57 PM UTC+1, Johnny wrote:
>    has expired and that they had items in their cart
>    - we destroy their session via `reset_session`
>    - we set up a new session for them
>    - we redirect them to the home page.
>
>
Are any of these  on different subdomains (eg some pages on
www.example.com
and some on example.com) ? If you had one session cookie set for
example.com and another for www.example.com (or some other subdomain)
then
you might see something like this,

Fred
Bb84647959d99f5abf6f2695865d06ce?d=identicon&s=25 Johnny (Guest)
on 2014-08-21 16:38
(Received via mailing list)
No, every request is to 'www.mydomain.com'.

Thanks.
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2014-08-22 16:01
(Received via mailing list)
On Thursday, August 21, 2014 3:37:27 PM UTC+1, Johnny wrote:
>
> No, every request is to 'www.mydomain.com'.
>
> Thanks.
>

Can you reproduce this in a browser you control? Would be interesting to
see what cookies the browser thinks it is storing for your domain.

Fred
Bb84647959d99f5abf6f2695865d06ce?d=identicon&s=25 Johnny (Guest)
on 2014-08-22 19:58
(Received via mailing list)
I have been unsuccessful in my attempts to reproduce it locally.

"Would be interesting to see what cookies the browser thinks it is
storing
for your domain."
I'm not sure what you mean by this.  I have been able to decode each
cookie
and see the contents.  One is just the old cookie data, and one is the
new.

Do you know of any way to check the path associated with a cookie
string?
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2014-08-22 20:30
(Received via mailing list)
On Friday, August 22, 2014 6:56:36 PM UTC+1, Johnny wrote:
> I have been unsuccessful in my attempts to reproduce it locally.
>
>
> "Would be interesting to see what cookies the browser thinks it is storing for
your domain."
> I'm not sure what you mean by this.  I have been able to decode each cookie and
see the contents.  One is just the old cookie data, and one is the new.
>
>
> Do you know of any way to check the path associated with a cookie string?
>

You'd be able to see that in the browser, if you could reproduce it -
that's what I meant. I don't think that data is sent to the server.

Fred
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.