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]
