Fix destroy so browser-side cookie session data is reset #6

wants to merge 2 commits into


None yet

3 participants


The current release deletes the cookie so it isn't sent, but doesn't erase it browser side so the session reappears on the next request. This pull request has a fix to ensure browser-side state is destroyed.

It also cleans up, slightly, how the cookie is written. Unfortunately, Dancer::Session::Abstract isn't sufficiently well factored so I had to copy code in from there and tweak it. Oh, well.

xdg added some commits Dec 6, 2012
@xdg xdg Destroy sessions in the cookie not just memory 3b16ab2
@xdg xdg Refactor cookie writing
flush and destroy now use write_session_id to update the cookie.

Unfortunately, that required copying that function from
Dancer::Session::Abstract and modifying it to support 'session_cookie_path'.

The upside is that Dancer::Session::Cookie now supports the
'session_domain' parameter.

How is the record of the cookie destroyed in the application shared-memory's "cookies" hash now? Doesn't the published patch just give a different session to an existing cookie?


I'm not sure deleting the existing cookies can be done given the current Dancer API. Fortunately, the last cookie set takes precedence.

I believe I have addressed this issue in Dancer2, however.


Aha! I think it is addressed. I override Dancer::Session::Abstract::write_session_id to do nothing, so when Dancer::Session::get_current_session calls it, no cookie gets set.

Instead, an after hook is used to set the cookie. So the cookie should only get set once and only after the request has finished.

@dagolden dagolden closed this Feb 6, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment