Hi Martin, many thanks for your help!!! I'll try to reproduce this in a quickstart. Temporarily I use my quick fix.
Regards, Thomas -----Ursprüngliche Nachricht----- Von: Martin Grigorov <[email protected]> Gesendet: Mi 04.04.2012 12:21 Betreff: Re: Wicket session id not up to date due to Tomcat session fixation protection An: [email protected]; > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
