#1601 reset_session Doesn't Result In New Session Id Being Applied Via Set-Cookie - Ruby on Rails

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

This project is archived and is in readonly mode.

#1601 ✓resolved

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 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
You flagged this item as spam.
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.
You flagged this item as spam.
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 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
You flagged this item as spam.
Matt Bauer December 20th, 2008 @ 06:52 PM
- Tag changed from “rack, session” to “patch, rack, session”
Added a reset! and reset? to SessionHash.
- reset_session_fix.diff 5.5 KB
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
```
Updated

Looks like this will work, patching right now.
```
if !session_data.is_a?(AbstractStore::SessionHash) || session_data.send(:loaded?)
```
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 josh@joshpeek.com http://github.com/rails/rails/co...
You flagged this item as spam.
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
You flagged this item as spam.
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:

http://github.com/rails/rails/co...

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.
You flagged this item as spam.
Mislav February 27th, 2009 @ 07:22 PM
Confirmed. Yury's fix works
You flagged this item as spam.
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
You flagged this item as spam.
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.
You flagged this item as spam.
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.
You flagged this item as spam.
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.
You flagged this item as spam.
thedarkone March 9th, 2009 @ 02:41 PM
Pre 2.1 "Passengers" are not compatible with Rails 2.3.x.

See: http://blog.phusion.nl/2009/03/0...

"What’s new in 2.1.1? Support for Rails 2.3"
You flagged this item as spam.
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