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 <t...@ordix.de> 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 <mgrigo...@apache.org>
> Gesendet: Mi 04.04.2012 11:10
> Betreff: Re: Wicket session id not up to date due to Tomcat session
> fixation protection
> An: users@wicket.apache.org;
>> 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 <t...@ordix.de> wrote:
>> > Hi Martin,
>> >
>> > see inline.
>> >
>> > Thanks!
>> > Thomas
>> >
>> > -----Ursprüngliche Nachricht-----
>> > Von: Martin Grigorov <mgrigo...@apache.org>
>> > Gesendet: Mi 04.04.2012 10:26
>> > Betreff: Re: Wicket session id not up to date due to Tomcat session
>> fixation protection
>> > An: users@wicket.apache.org;
>> >> Hi Thomas,
>> >>
>> >> On Wed, Apr 4, 2012 at 10:18 AM, Thomas Rohde <t...@ordix.de> 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 <mgrigo...@apache.org>
>> >> > Gesendet: Mi 04.04.2012 09:39
>> >> > Betreff: Re: Wicket session id not up to date due to Tomcat
>> >> > session
>> >> fixation protection
>> >> > An: users@wicket.apache.org;
>> >> >> 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 <t...@ordix.de> 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: users-unsubscr...@wicket.apache.org
>> >> >> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Martin Grigorov
>> >> >> jWeekend
>> >> >> Training, Consulting, Development
>> >> >> http://jWeekend.com
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Martin Grigorov
>> >> jWeekend
>> >> Training, Consulting, Development
>> >> http://jWeekend.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
