With a quickstart I'll be more certain what exactly happens and how to solve it the best way... Until then use this solution since it works for you.
On Wed, Apr 4, 2012 at 12:11 PM, Thomas Rohde <[email protected]> wrote: > Okay a better attempt: > > I tried your suggestion to overwrite the replaceSession method of the Session > class. It didn't work. > > But now I modified the lookup method of the AbstractHttpSessionStore like the > following: > > 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); > > // it cannot be okay if the session id's are not equal!!! > if (null != session && !sessionId.equals(session.getId())) { > try { > Field f = Session.class.getDeclaredField("id"); > f.setAccessible(true); > f.set(session, null); // it will be resolved later from the > httpSession > } catch (Exception e) { > throw new IllegalStateException(e); > } > } > return session; > } > return null; > } > > That seems to work. Is it a valid solution? > > Thomas > > -----Ursprüngliche Nachricht----- > Von: Martin Grigorov <[email protected]> > Gesendet: Mi 04.04.2012 11:43 > Betreff: Re: Wicket session id not up to date due to Tomcat session > fixation protection > An: [email protected]; >> Sorry. >> I didn't understand you. >> >> A quickstart will make it easier for me to help you. >> >> On Wed, Apr 4, 2012 at 11:39 AM, Thomas Rohde <[email protected]> wrote: >> > 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] >> > >> >> >> >> -- >> 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]
