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]
