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