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]
Igor,
I thought that as long as you only use stateless pages and don't throw
RestartResponseExceptions 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
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
RestartResponseExceptions the http session
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: users@wicket.apache.org
Subject: Re: Authentication and Assigning a Session Id
yes, if all that is true
:[EMAIL PROTECTED]
Sent: Mon 3/10/2008 4:24 PM
To: users@wicket.apache.org
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
@wicket.apache.org
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
with
the original data.
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Mon 3/10/2008 6:00 PM
To: users@wicket.apache.org
Subject: Re: Authentication and Assigning a Session Id
wicket's Session has invalidate() and invalidateNow()
-igor
