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]
