Why does the the cookie_string have two entries for my site?

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

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

No, every request is to ‘www.mydomain.com’.

Thanks.

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

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?

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