We've invested some more research on this topic because session.invalidate didn't work and came up with a solution. We've created a JIRA-Ticket regarding this topic to document our solution.
https://issues.apache.org/jira/browse/WICKET-1767 Regards Enes F. On Wed, Jul 30, 2008 at 5:59 PM, Igor Vaynberg <[EMAIL PROTECTED]>wrote: > doing that should be fine, just make sure that after login you > redirect to a bookmarkable url which will then create a new session. > > so > session.invalidate(); > loginuser(); > setrequesttarget(new bookmarkablepagetarget(...)); > getrequest().setredirect(true); > > -igor > > On Wed, Jul 30, 2008 at 7:15 AM, Enes Fazli <[EMAIL PROTECTED]> > wrote: > > Hi wicket users, > > > > we are currently in the process of securing our Wicket-powered > > application against various attack vectors. One of them is Session > > Fixation, as described here: > > http://www.owasp.org/index.php/Session_Fixation > > > > The recommended protection in Java is to invalidate the Session before > > authenticating the user, with something like this: > > > > HttpSession s = request.getSession(false); > > if (s != null) s.invalidate(); > > s = request.getSession(true); > > > > Invalidating the session can be done with Session.get().invalidate() > > or invalidateNow(), but that leaves, as far as I can tell, Wicket's > > Session in a broken state, preventing the login alltogether. > > > > Instead of continuing to tamper with Wicket internals, is there a > > solution available? > > > > Regards, > > > > Enes F. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
