This project is archived and is in readonly mode.

#1601 ✓resolved
Matt Bauer

reset_session Doesn't Result In New Session Id Being Applied Via Set-Cookie

Reported by Matt Bauer | December 19th, 2008 @ 05:49 AM

After calling reset_session in a controller the session is properly reset and set to nil. However, the session cookie value isn't updated and as a result, a subsequent request from the browser sends the old session id. This results in the old session being retrieved and appearing as if reset_session didn't work. Prior to the recent Rack integration the following was observed:

A request to a session destroy action that called reset_session would send a cookie like:

Cookie _pas_session=BAh7CjoQX2N...

and Rails would respond with a Set-Cookie header like:

Set-Cookie _pas_session=BAh7BiIKZmx...

After the Rack integration of late, this has changed to:

A request to a session destroy action that called reset_session would send a cookie like:

Cookie _pas_session=BAh7CjoQX2N...

and now Rails doesn't respond with a Set-Cookie header. Again, this results in the browser resending the old cookie on the subsequent request.

Comments and changes to this ticket

  • josh

    josh December 19th, 2008 @ 05:57 AM

    • Milestone cleared.
    • State changed from “new” to “open”

    Definitely something I need to address.

    You are running Edge, right? Lots of rack session changes went in very recently.

    Also, if you can come up with a fix, can you try to put together a failing unit test.

    Check out actionpack/test/controller/session/cookie_store

  • Matt Bauer

    Matt Bauer December 19th, 2008 @ 06:01 AM

    Yes, I'm currently running the very latest commit. I'm also in the process of working on cookie_store_test trying to recreate the bug. I'm hopeful I can get a patch together yet tonite. Shouldn't be a problem once I can create the failing test.

  • Matt Bauer

    Matt Bauer December 19th, 2008 @ 08:06 AM

    I had a little more time to investigate this. I wasn't able to create a test to recreate the behavior I'm seeing. I was able to debug it a bit more. I can get the proper behavior of:

    Set-Cookie: session_key=1221362112abcd..

    after a reset_session if I place something in the session after the call to reset_session. I thought it was the equals check of:

    unless original_session == env[ENV_SESSION_KEY]

    in cookie_store/activerecord_store but when I force this to fail and generate the cookie each time, the problem didn't go away. I'm not sure where else the cookie header is set.

    I do know reset_session only works only if you place something in the new session.

  • josh

    josh December 19th, 2008 @ 04:30 PM

    Ah, it doesn't want to write an empty session.

    There are a few behaviors we want to preserve as well:

    • Don't load or write a new session if the session hash is never accessed (lazy loading)
    • Don't write the session cookie if it is the same as the original
    • For DB stores, don't write the session object back to memcache or AR if the session has not changed
    • Only write an empty session if the session existed at the beginning of the session, but now is empty. You deleted all the keys or you called reset_session
  • Matt Bauer

    Matt Bauer December 20th, 2008 @ 06:52 PM

    • Tag changed from rack, session to patch, rack, session

    Added a reset! and reset? to SessionHash.

  • josh

    josh December 20th, 2008 @ 08:05 PM

    Cool, I think this is on the right track but we can't assume @env['rack.session'] will respond to reset!. This should work with other Rack stores as well.

    Could we just check?

    if env[ENV_SESSION_KEY].loaded? && env[ENV_SESSION_KEY] != original_value


    Looks like this will work, patching right now.

    if !session_data.is_a?(AbstractStore::SessionHash) || session_data.send(:loaded?)
  • Repository

    Repository December 20th, 2008 @ 08:38 PM

    • State changed from “open” to “resolved”

    (from [7b249b67e9df9f375eaad9e6eb41be73338faaa7]) Fix reset_session with lazy cookie stores [#1601 state:resolved]

    Signed-off-by: Joshua Peek

  • Yury Kotlyarov

    Yury Kotlyarov February 18th, 2009 @ 10:32 PM

    doesn't work for me. in mongrel works after adding

    session[:is_new] = true

    but in passenger still restores old session.

    solved by

    headers['Set-Cookie'] = ''

    after reset_session call

  • Duff OMelia

    Duff OMelia February 19th, 2009 @ 03:23 PM

    reset_session seems to be working perfectly for me using mongrel as well. In passenger though, I can't seem to logout of my site. I used git bisect and I'm able to logout perfectly fine in Passenger up until this commit:

    I haven't yet determined what it is in that commit (or if it's something that Passenger needs to update or has already updated.) I'm using 2.06 of passenger which I think is the latest.

  • Mislav

    Mislav February 27th, 2009 @ 07:22 PM

    Confirmed. Yury's fix works

  • Mislav

    Mislav March 3rd, 2009 @ 02:28 PM

    This seems to be a bug with Passenger: reset_session fails only with Passenger 2.0.6, not with Mongrel. Upgrading to edge Passenger solves the issue for me

  • Kip Cole

    Kip Cole March 9th, 2009 @ 02:29 AM

    I think this is the same (or related) issue as cookie_store session object not being serialized if it is only written, not read in a request. This is the behaviour with Phusion 2.0.6.

    The cookie is serialized properly in Mongrel with the same code.

    As a workaround I add a before filter to the app to access the session object, which appears to then result in the correct serialization with Phusion.

    This is on current edge rails.

  • Kip Cole

    Kip Cole March 9th, 2009 @ 03:23 AM

    Hmm, i was incorrect. Adding the before_filter to access the session does not work around the Phusion issue.

  • Randy Schmidt

    Randy Schmidt March 9th, 2009 @ 03:52 AM

    Is this flying under the radar because it's marked as resolved? I'm having the same issues as everybody above on rails 2.3.1. I'm still poking around so I don't have anything of value to add.

  • thedarkone

    thedarkone March 9th, 2009 @ 02:41 PM

    Pre 2.1 "Passengers" are not compatible with Rails 2.3.x.


    "What’s new in 2.1.1? Support for Rails 2.3"

  • almightylinuxgod (at me)

    almightylinuxgod (at me) February 18th, 2011 @ 04:25 AM

    • Importance changed from “” to “”

    Just wondering if this resolution was in 3.0.4, or 3.0.5

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>


Referenced by