same us you would do with http session directly i guess...

-igor


On Mon, Mar 10, 2008 at 6:08 PM, Zappaterrini, Larry
<[EMAIL PROTECTED]> wrote:
> That was my initial inclination, but I don't see an easy way to get the data 
> out of the session, request a new session, then populate the new session with 
> the original data.
>
>
>
>  ________________________________
>
>  From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>  Sent: Mon 3/10/2008 6:00 PM
>
>
> To: [email protected]
>  Subject: Re: Authentication and Assigning a Session Id
>
>
>
>  wicket's Session has invalidate() and invalidateNow()
>
>  -igor
>
>
>  On Mon, Mar 10, 2008 at 1:38 PM, Zappaterrini, Larry
>  <[EMAIL PROTECTED]> wrote:
>  > While it is true that the jsessionid token is not controlled by 
> application code, you can request a new one be generated by calling 
> invalidate on the session then request a new session by calling 
> getSession(true) on the request as I mentioned in my original message. 
> Essentially it creates the illusion of one contiguous session to the user 
> when it is actually two different sessions. I suppose I could attempt to do 
> the same thing from within my application code in Wicket and use the HTTP 
> request to accomplish it. I was just hoping to preserve Wicket's approach of 
> treating HTTP as an implementation detail and not having to include any 
> references to it in my code.
>  >
>  >  ________________________________
>  >
>  >  From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>  >  Sent: Mon 3/10/2008 4:24 PM
>  >  To: [email protected]
>  >  Subject: Re: Authentication and Assigning a Session Id
>  >
>  >
>  >
>  >
>  >
>  >  yes, if all that is true. but you still do not control the jsessionid 
> token...
>  >
>  >  -igor
>  >
>  >
>  >  On Mon, Mar 10, 2008 at 1:21 PM, Maurice Marrink <[EMAIL PROTECTED]> 
> wrote:
>  >  > Igor,
>  >  >
>  >  >  I thought that as long as you only use stateless pages and don't throw
>  >  >  RestartResponse....Exceptions the http session remained temporary (as
>  >  >  in is not assigned an id).
>  >  >
>  >  >  Anyway Wicket-Security automatically binds the wicket session (assigns
>  >  >  id to http session) after a successful login, if the session is not
>  >  >  already bound. But there is no guarantee that the session is not bound
>  >  >  until then.
>  >  >
>  >  >  Maurice
>  >  >
>  >  >
>  >  >
>  >  >  On Mon, Mar 10, 2008 at 9:01 PM, Igor Vaynberg <[EMAIL PROTECTED]> 
> wrote:
>  >  >  > session management is handled by the servlet container and is outside
>  >  >  >  wicket's control. perhaps you can use a cookie in conjunction with a
>  >  >  >  check in requestcycle.onbeginrequest to do something like what you
>  >  >  >  want...
>  >  >  >
>  >  >  >  -igor
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >  On Mon, Mar 10, 2008 at 12:43 PM, Zappaterrini, Larry
>  >  >  >  <[EMAIL PROTECTED]> wrote:
>  >  >  >  > Hi Everyone,
>  >  >  >  >
>  >  >  >  >  Is it possible to control when Wicket issues a valid session 
> identifier to the user? The use case I am trying to support is only assign a 
> valid session id to the user after they successfully authenticate. This is 
> important to prevent possible session hijacking. When dealing with HTTP 
> sessions directly you can copy the session contents, invalidate the session, 
> request a new session, and put the contents of the original session into the 
> new one. I've browsed through some of Wicket's source code to see if this is 
> easily accomplished but I haven't been able to figure it out. Does anyone 
> have any input or suggestions?
>  >  >  >  >
>  >  >  >  >  Thanks,
>  >  >  >  >  Larry
>  >  >  >  >
>  >  >  >  >
>  >  >  >  >  ______________
>  >  >  >  >
>  >  >  >  >  The information contained in this message is proprietary and/or 
> confidential. If you are not the
>  >  >  >  >  intended recipient, please: (i) delete the message and all 
> copies; (ii) do not disclose,
>  >  >  >  >  distribute or use the message in any manner; and (iii) notify 
> the sender immediately. In addition,
>  >  >  >  >  please be aware that any message addressed to our domain is 
> subject to archiving and review by
>  >  >  >  >  persons other than the intended recipient. Thank you.
>  >  >  >  >  _____________
>  >  >  >
>  >  >  >  
> ---------------------------------------------------------------------
>  >  >  >  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]
>  >  >
>  >  >
>  >
>  >  ---------------------------------------------------------------------
>  >  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  >  For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>  >
>  >  ______________
>  >
>  >  The information contained in this message is proprietary and/or 
> confidential. If you are not the
>  >  intended recipient, please: (i) delete the message and all copies; (ii) 
> do not disclose,
>  >  distribute or use the message in any manner; and (iii) notify the sender 
> immediately. In addition,
>  >  please be aware that any message addressed to our domain is subject to 
> archiving and review by
>  >  persons other than the intended recipient. Thank you.
>  >  _____________
>  >
>  > ---------------------------------------------------------------------
>  >  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]
>
>
>
>  ______________
>
>  The information contained in this message is proprietary and/or 
> confidential. If you are not the
>  intended recipient, please: (i) delete the message and all copies; (ii) do 
> not disclose,
>  distribute or use the message in any manner; and (iii) notify the sender 
> immediately. In addition,
>  please be aware that any message addressed to our domain is subject to 
> archiving and review by
>  persons other than the intended recipient. Thank you.
>  _____________
>
> ---------------------------------------------------------------------
>  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]

Reply via email to