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.
