Session.replaceSession() behavior

[Doug Leeper <do...@yahoo.com>]

I was under the impression that when I call Session.replaceSession() a new session would be created.

I am seeing a new HttpServletSession being created but not my wicket application session.  I have placed a System.out.println( "new AppSession()..." ) in the constructor and I am not seeing that.

Can anyone confirm this behavior as well?  Is this a bug?  Is there a work around?

I am using Wicket 1.4.9

BTW...my use case is someone goes to the LoginPage and logs in, the previous session will be cleared.

Multi-window support is also on (however...changing this doesn't affect the outcome)

Thanks
- Doug

Re: Session.replaceSession() behavior

[Matthias Keller <ma...@ergon.ch>]

Hi Doug

As described in the javadoc, the replaceSession() only replaces the 
(underlying) HTTP Session to help against session fixation attacks.
What is your goal exactly? If the user logs in and still has an earlier 
session, that that one will be destroyed?
In that case consider to use  session.invalidateNow()  to immediately 
destroy the (old) session and then create a new one.
Notice: When using invalidateNow() and creating a new one, the static 
method  Session.get() will still get you the previous (destroyed) 
session while being in the same call...

Matt

On 2010-06-24 20:13, Doug Leeper wrote:
> I was under the impression that when I call Session.replaceSession() a new session would be created.
>
> I am seeing a new HttpServletSession being created but not my wicket application session.  I have placed a System.out.println( "new AppSession()..." ) in the constructor and I am not seeing that.
>
> Can anyone confirm this behavior as well?  Is this a bug?  Is there a work around?
>
> I am using Wicket 1.4.9
>
> BTW...my use case is someone goes to the LoginPage and logs in, the previous session will be cleared.
>
> Multi-window support is also on (however...changing this doesn't affect the outcome)
>
> Thanks
> - Doug
>