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]
