[jira] Resolved: (WICKET-2014) Deleting cookies doesn't reset the active wicket session for a client.

["Igor Vaynberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg resolved WICKET-2014.
-----------------------------------

    Resolution: Cannot Reproduce

> Deleting cookies doesn't reset the active wicket session for a client.
> ----------------------------------------------------------------------
>
>                 Key: WICKET-2014
>                 URL: https://issues.apache.org/jira/browse/WICKET-2014
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.4-RC1
>            Reporter: Maarten Billemont
>
> Related to https://issues.apache.org/jira/browse/WICKET-2013, after that event occurred; wicket enters a state where deleting the browser's cookies doesn't actually make the client get rid of the active session.
> I have to admit I've looked through the code but am none the wiser at what could *possibly* be going on, because as far as wicket is concearned, a client without cookies to identify a session ID *cant possibly* end up on the same session as a client that DID, right?
> The case is caused by this:
> 1. Cause the action described in WICKET-2013.  Preferably through a means of browsing to a page, clicking a button to set a session property on your wicket session; and then making the page invalidate & throw exception when that wicket session property is set.
> 2. Click the button to set the session property & cause the exception.
> 3. Delete your browser cache.
> 4. Go back to that page:  You still get the exception.  The session still has the name attribute!
> 5. Open a different browser to the page: You still get the exception!
> 6. On a different machine, open the page, it should show the button, as expected.  You had no active session.
> 7. Click the button, you should get the exception again; and be in the same state as the first machine was in starting from (2.)
> Okay, the Session.get().invalidate() doesn't go through because the exception is thrown (That's the bug WICKET-2013 deals with); but this bug questions why this exception can't be avoided by cleaning up your cookies.  That should've manually unlinked your browser from the wicket session that has the name property in it.
> I'm thinking perhaps the ""java.lang.IllegalStateException: Request processing executed 100 steps, which means it is probably in an infinite loop."" that wicket throws causes an early abort in wicket, which in turn might cause the session to somehow remain on the active wicket thread (not unset from a threadlocal), which might cause any subsequent requests, be they from an active servletsession or not, to enter the same thread which still has the old wicketsession set on it?  But I'm not even sure that's possible (the unset method of the session threadlocal is in a finally block).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.