Hi Martin, I already did that (I wrote above). But the problem still exists. I cannot see from where wicket gets the old and wrong session id.
Thomas -----Ursprüngliche Nachricht----- Von: Martin Grigorov <[email protected]> Gesendet: Mi 04.04.2012 11:10 Betreff: Re: Wicket session id not up to date due to Tomcat session fixation protection An: [email protected]; > Hi Thomas, > > Temporarily until there is a fix you can override #replaceSession() to > look like: > super.replaceSession(); > Field idField = getField("id"); > idField.setAccessible(true); > idField.set(this, null); > > I.e. null-ify the cached session id in Session. > > > On Wed, Apr 4, 2012 at 10:57 AM, Thomas Rohde <[email protected]> wrote: > > Hi Martin, > > > > see inline. > > > > Thanks! > > Thomas > > > > -----Ursprüngliche Nachricht----- > > Von: Martin Grigorov <[email protected]> > > Gesendet: Mi 04.04.2012 10:26 > > Betreff: Re: Wicket session id not up to date due to Tomcat session > fixation protection > > An: [email protected]; > >> Hi Thomas, > >> > >> On Wed, Apr 4, 2012 at 10:18 AM, Thomas Rohde <[email protected]> wrote: > >> > Hi Martin, > >> > > >> > but the AbstractHttpSesionStore has a SessionBindingListener which > >> > stores > the > >> session id and the Session class has an id member variable. > >> > >> This is improved in 6.x and the session is taken from the passed > >> event. I can backport it to 1.5.x too. > > > > Please take a look at this. I put some log statements in the session class. > For me the lookup method looks weird. Take a look at the following code: > > > > public Session lookup(Request request) { > > String sessionId = getSessionId(request, false); > > LOG.debug("AbstractHttpSessionStore#lookup() [sessionId={}]", sessionId); > > if (sessionId != null) { > > WebRequest webRequest = toWebRequest(request); > > Session session = (Session)getAttribute(webRequest, > Session.SESSION_ATTRIBUTE_NAME); > > LOG.debug("AbstractHttpSessionStore#lookup() [getAttribute()={}] > [session={}]", > > (null != session) ? session.getId() : "null", session); > > return session; > > } > > return null; > > } > > > > The first log output produces > > AbstractHttpSessionStore#lookup() > > [sessionId=A8F69FB8C2119439FC90CFD647115D51] > > > > The second produces the following > > AbstractHttpSessionStore#lookup() > [getAttribute()=9F4CECDC89947EFEF5B7646F6600A8B8] > [session=de.postbank.ucp.application.face.session.FaceWebSession@3cf08d9e] > > > > The getAttribute resolves the session object but the session id within the > session object is not the same as the session id from getSessionId(request, > false) which is the one of the httpSession object from the underlying web > container. Can you explain this to me? > > > >> > >> > > >> > The getId() implementation of the Session class uses the following logic: > >> > > >> > if (id == null) > >> > id = getSessionStore().getSessionId(RequestCycle.get().getRequest(), > false); > >> > > >> > After our login procedure Session.getId() is never equal to > >> httpSession.getId() > >> > >> This deserves a ticket - the 'id' member should be reset to 'null' in > >> #replaceSession(). > > > > I tested it via reflection, but did not solve the problem. > > > >> > >> Please file a ticket. > >> > >> > > >> > Thomas > >> > > >> > -----Ursprüngliche Nachricht----- > >> > Von: Martin Grigorov <[email protected]> > >> > Gesendet: Mi 04.04.2012 09:39 > >> > Betreff: Re: Wicket session id not up to date due to Tomcat > >> > session > >> fixation protection > >> > An: [email protected]; > >> >> Hi Thomas, > >> >> > >> >> Wicket doesn't store anything in its session store. > >> >> It always uses the currently active http session to get the id. > >> >> See > >> >> > >> > org.apache.wicket.protocol.http.AbstractHttpSessionStore#getSessionId(Request, > >> >> boolean) > >> >> > >> >> On Wed, Apr 4, 2012 at 9:27 AM, Thomas Rohde <[email protected]> wrote: > >> >> > Hi! > >> >> > > >> >> > We are using Wicket 1.4.20 and Tomcat 7.0.21. > >> >> > > >> >> > After form based authentication (configured in web.xml) we call > >> >> wicketSession.replaceSession() in the constructor of our base page and > send a > >> >> redirect to our welcome page. Due to tomcat's session fixation > >> >> protection > the > >> >> session id changes for some times. After rendering the welcome page the > >> session > >> >> id stored in wicket's session store is not equal to the JSESSIONID. > >> >> > > >> >> > Are we doing anything wrong? Any idea? > >> >> > > >> >> > Regards, > >> >> > Thomas > >> >> > > >> >> > --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: [email protected] > >> >> > For additional commands, e-mail: [email protected] > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Martin Grigorov > >> >> jWeekend > >> >> Training, Consulting, Development > >> >> http://jWeekend.com > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> >> > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > >> > >> > >> -- > >> Martin Grigorov > >> jWeekend > >> Training, Consulting, Development > >> http://jWeekend.com > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
