You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Andreas Prohaska <ap...@apeiron.de> on 2001/06/06 13:15:57 UTC
Handling session timeouts
This was originally posted to the struts-user list, but Ted Husted pointed
out that I should better discuss this on the development list.
For the guys that are not listening to the user list, the background: We
have written a wizard for a larger input process that requires some steps.
We use one ActionForm bean for this wizard that keeps the data in the
session context (everything done by struts). When I wanted to go to the next
step I recognized that all my data from the previous steps was lost and
instead I had the default values. Obviously a session timeout occured and
the original ActionForm was removed. Then a new session was automatically
created and a new ActionForm bean was automatically added to the session
context. Normally this is nice, but there was no way for my Action class or
JSP to see that in fact the session was lost and the data was wrong.
Now I would recommend to place a method like processSession() at the start
of the process() method in the ActionServlet. This could be changed by
subclasses of the ActionServlet in order to intercept session creation and
deprecation. OR it should call some more specialized class for this (say
SessionManager). The advantage of this approach would be that we could also
introduce a new <page:init> tag that calls the same class in order to
intercept session creation in JSP pages (that might be called directly).
If the list decides that this could be nice, I would make the changes but
then I need to know how I can submit them :-)
What do you think?
Andreas
------------------------------------------------------------------------
Andreas Prohaska Mail: prohaska@apeiron.de
Apeiron GmbH Tel : +49 (089) 278257-40
Hohenzollernstr. 81 Fax : +49 (089) 278257-49
80796 Muenchen
------------------------------------------------------------------------
Re: Handling session timeouts
Posted by Jonathan Asbell <ja...@i-2000.com>.
implement something using the HttpSessionBindingListener. We could
serialize the data, or at least know that we lost the session data
----- Original Message -----
From: "Andreas Prohaska" <ap...@apeiron.de>
To: <st...@jakarta.apache.org>
Sent: Wednesday, June 06, 2001 7:15 AM
Subject: Handling session timeouts
>
> This was originally posted to the struts-user list, but Ted Husted pointed
> out that I should better discuss this on the development list.
>
> For the guys that are not listening to the user list, the background: We
> have written a wizard for a larger input process that requires some steps.
> We use one ActionForm bean for this wizard that keeps the data in the
> session context (everything done by struts). When I wanted to go to the
next
> step I recognized that all my data from the previous steps was lost and
> instead I had the default values. Obviously a session timeout occured and
> the original ActionForm was removed. Then a new session was automatically
> created and a new ActionForm bean was automatically added to the session
> context. Normally this is nice, but there was no way for my Action class
or
> JSP to see that in fact the session was lost and the data was wrong.
>
> Now I would recommend to place a method like processSession() at the start
> of the process() method in the ActionServlet. This could be changed by
> subclasses of the ActionServlet in order to intercept session creation and
> deprecation. OR it should call some more specialized class for this (say
> SessionManager). The advantage of this approach would be that we could
also
> introduce a new <page:init> tag that calls the same class in order to
> intercept session creation in JSP pages (that might be called directly).
>
> If the list decides that this could be nice, I would make the changes but
> then I need to know how I can submit them :-)
>
> What do you think?
>
> Andreas
>
> ------------------------------------------------------------------------
> Andreas Prohaska Mail: prohaska@apeiron.de
> Apeiron GmbH Tel : +49 (089) 278257-40
> Hohenzollernstr. 81 Fax : +49 (089) 278257-49
> 80796 Muenchen
> ------------------------------------------------------------------------
>
Re: Handling session timeouts
Posted by Ron Smith <ro...@rpsenterprises.com>.
I think a hook into session creation would be good. I'd think the
scenario you describe would be pretty common. I know we did
pretty much what you describe for a non-struts based app. I wonder if
people are doing no session handling by overriding
processPreprocess() or perhaps in the action class?
I'm thinking it'd be nice to make the no session condition an event
that is generated by the ActionServlet and acted upon by any registered
listeners
(See "Event and Listener Model" on the 1.1 todo list).
That way, I could install a listener that handles the no session condition
by forwarding the user to some action forward without overriding
processSession(). The listener class to be registered could be
specified in the configuration file. It'd also be nice to be able to reuse
the same no session listener across multiple projects if they're all
doing the same thing (forwarding to some session timeout page).
Perhaps the default processSession() implementation would fire off
this event, so you could override the no session handling at the
processSession() function level, or by installing an event listener.
I don't know how far off the "Event and Listener Model" work is.
Perhaps we could put in a processSession() hook that does
nothing now, and look at making it generate an event later.
Andreas Prohaska wrote:
> This was originally posted to the struts-user list, but Ted Husted pointed
> out that I should better discuss this on the development list.
>
> For the guys that are not listening to the user list, the background: We
> have written a wizard for a larger input process that requires some steps.
> We use one ActionForm bean for this wizard that keeps the data in the
> session context (everything done by struts). When I wanted to go to the next
> step I recognized that all my data from the previous steps was lost and
> instead I had the default values. Obviously a session timeout occured and
> the original ActionForm was removed. Then a new session was automatically
> created and a new ActionForm bean was automatically added to the session
> context. Normally this is nice, but there was no way for my Action class or
> JSP to see that in fact the session was lost and the data was wrong.
>
> Now I would recommend to place a method like processSession() at the start
> of the process() method in the ActionServlet. This could be changed by
> subclasses of the ActionServlet in order to intercept session creation and
> deprecation. OR it should call some more specialized class for this (say
> SessionManager). The advantage of this approach would be that we could also
> introduce a new <page:init> tag that calls the same class in order to
> intercept session creation in JSP pages (that might be called directly).
>
> If the list decides that this could be nice, I would make the changes but
> then I need to know how I can submit them :-)
>
> What do you think?
>
> Andreas
>
> ------------------------------------------------------------------------
> Andreas Prohaska Mail: prohaska@apeiron.de
> Apeiron GmbH Tel : +49 (089) 278257-40
> Hohenzollernstr. 81 Fax : +49 (089) 278257-49
> 80796 Muenchen
> ------------------------------------------------------------------------
Re: Handling session timeouts
Posted by Jonathan Asbell <ja...@i-2000.com>.
why not use the token mechanism. Doesnt it handle this already?
----- Original Message -----
From: "Martin Cooper" <ma...@tumbleweed.com>
To: <st...@jakarta.apache.org>
Sent: Sunday, June 10, 2001 2:02 AM
Subject: Re: Handling session timeouts
> Why not just add a property to your form bean to detect this? Then you can
> do the following:
>
> - When the bean is constructed, the 'valid' property is set to false.
> - When the action sets up the bean for display, it sets 'valid' to true.
> - The JSP checks the 'valid' property before using the values from the
form
> bean.
>
> This way, if the form bean is created by Struts, but not populated by your
> action, the 'valid' property will be false, thus detecting the situation
you
> described.
>
> Hope this helps.
>
> --
> Martin Cooper
>
>
> ----- Original Message -----
> From: "Andreas Prohaska" <ap...@apeiron.de>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, June 06, 2001 4:15 AM
> Subject: Handling session timeouts
>
>
> >
> > This was originally posted to the struts-user list, but Ted Husted
pointed
> > out that I should better discuss this on the development list.
> >
> > For the guys that are not listening to the user list, the background: We
> > have written a wizard for a larger input process that requires some
steps.
> > We use one ActionForm bean for this wizard that keeps the data in the
> > session context (everything done by struts). When I wanted to go to the
> next
> > step I recognized that all my data from the previous steps was lost and
> > instead I had the default values. Obviously a session timeout occured
and
> > the original ActionForm was removed. Then a new session was
automatically
> > created and a new ActionForm bean was automatically added to the session
> > context. Normally this is nice, but there was no way for my Action class
> or
> > JSP to see that in fact the session was lost and the data was wrong.
> >
> > Now I would recommend to place a method like processSession() at the
start
> > of the process() method in the ActionServlet. This could be changed by
> > subclasses of the ActionServlet in order to intercept session creation
and
> > deprecation. OR it should call some more specialized class for this (say
> > SessionManager). The advantage of this approach would be that we could
> also
> > introduce a new <page:init> tag that calls the same class in order to
> > intercept session creation in JSP pages (that might be called directly).
> >
> > If the list decides that this could be nice, I would make the changes
but
> > then I need to know how I can submit them :-)
> >
> > What do you think?
> >
> > Andreas
> >
> > ------------------------------------------------------------------------
> > Andreas Prohaska Mail: prohaska@apeiron.de
> > Apeiron GmbH Tel : +49 (089) 278257-40
> > Hohenzollernstr. 81 Fax : +49 (089) 278257-49
> > 80796 Muenchen
> > ------------------------------------------------------------------------
>
>
Re: Handling session timeouts
Posted by Martin Cooper <ma...@tumbleweed.com>.
Why not just add a property to your form bean to detect this? Then you can
do the following:
- When the bean is constructed, the 'valid' property is set to false.
- When the action sets up the bean for display, it sets 'valid' to true.
- The JSP checks the 'valid' property before using the values from the form
bean.
This way, if the form bean is created by Struts, but not populated by your
action, the 'valid' property will be false, thus detecting the situation you
described.
Hope this helps.
--
Martin Cooper
----- Original Message -----
From: "Andreas Prohaska" <ap...@apeiron.de>
To: <st...@jakarta.apache.org>
Sent: Wednesday, June 06, 2001 4:15 AM
Subject: Handling session timeouts
>
> This was originally posted to the struts-user list, but Ted Husted pointed
> out that I should better discuss this on the development list.
>
> For the guys that are not listening to the user list, the background: We
> have written a wizard for a larger input process that requires some steps.
> We use one ActionForm bean for this wizard that keeps the data in the
> session context (everything done by struts). When I wanted to go to the
next
> step I recognized that all my data from the previous steps was lost and
> instead I had the default values. Obviously a session timeout occured and
> the original ActionForm was removed. Then a new session was automatically
> created and a new ActionForm bean was automatically added to the session
> context. Normally this is nice, but there was no way for my Action class
or
> JSP to see that in fact the session was lost and the data was wrong.
>
> Now I would recommend to place a method like processSession() at the start
> of the process() method in the ActionServlet. This could be changed by
> subclasses of the ActionServlet in order to intercept session creation and
> deprecation. OR it should call some more specialized class for this (say
> SessionManager). The advantage of this approach would be that we could
also
> introduce a new <page:init> tag that calls the same class in order to
> intercept session creation in JSP pages (that might be called directly).
>
> If the list decides that this could be nice, I would make the changes but
> then I need to know how I can submit them :-)
>
> What do you think?
>
> Andreas
>
> ------------------------------------------------------------------------
> Andreas Prohaska Mail: prohaska@apeiron.de
> Apeiron GmbH Tel : +49 (089) 278257-40
> Hohenzollernstr. 81 Fax : +49 (089) 278257-49
> 80796 Muenchen
> ------------------------------------------------------------------------
Re: Handling session timeouts
Posted by Jonathan Asbell <ja...@i-2000.com>.
No Craig. If his session times out, it will loose the token in the session.
Thus the page will not submit because the token in the session will not
match the one in the hidden field.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>; "Jonathan Asbell" <ja...@i-2000.com>
Sent: Monday, June 11, 2001 11:07 PM
Subject: Re: Handling session timeouts
>
>
> On Mon, 11 Jun 2001, Jonathan Asbell wrote:
>
> > Craig, I thoght the token mechanism could have helped here. Am I wrong?
>
> Tokens will definitely help avoid the problem of pressing Reload, or
> pressing Back Arrow and then submitting again, but they don't do anything
> particularly useful in regards to detecting timeouts.
>
> Craig
>
Re: Handling session timeouts
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 11 Jun 2001, Jonathan Asbell wrote:
> Craig, I thoght the token mechanism could have helped here. Am I wrong?
Tokens will definitely help avoid the problem of pressing Reload, or
pressing Back Arrow and then submitting again, but they don't do anything
particularly useful in regards to detecting timeouts.
Craig
Re: Handling session timeouts
Posted by Jonathan Asbell <ja...@i-2000.com>.
Craig, I thoght the token mechanism could have helped here. Am I wrong?
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Monday, June 11, 2001 10:30 PM
Subject: Re: Handling session timeouts
> On Wed, 6 Jun 2001, Andreas Prohaska wrote:
>
> >
> > This was originally posted to the struts-user list, but Ted Husted
pointed
> > out that I should better discuss this on the development list.
> >
> > For the guys that are not listening to the user list, the background: We
> > have written a wizard for a larger input process that requires some
steps.
> > We use one ActionForm bean for this wizard that keeps the data in the
> > session context (everything done by struts). When I wanted to go to the
next
> > step I recognized that all my data from the previous steps was lost and
> > instead I had the default values. Obviously a session timeout occured
and
> > the original ActionForm was removed. Then a new session was
automatically
> > created and a new ActionForm bean was automatically added to the session
> > context. Normally this is nice, but there was no way for my Action class
or
> > JSP to see that in fact the session was lost and the data was wrong.
> >
> > Now I would recommend to place a method like processSession() at the
start
> > of the process() method in the ActionServlet. This could be changed by
> > subclasses of the ActionServlet in order to intercept session creation
and
> > deprecation. OR it should call some more specialized class for this (say
> > SessionManager). The advantage of this approach would be that we could
also
> > introduce a new <page:init> tag that calls the same class in order to
> > intercept session creation in JSP pages (that might be called directly).
> >
> > If the list decides that this could be nice, I would make the changes
but
> > then I need to know how I can submit them :-)
> >
> > What do you think?
> >
>
> In servlet 2.2, there is *no* general event handling mechanism that can
> catch a session creation no matter where it happened. In order to make
> something like this work in Struts, we would have to place restrictions
> like this:
>
> * The action cannot call request.getSession() -- it must call some
> Struts-provided method that will detect the creation.
>
> * The user cannot *ever* call a JSP page directly, because the session
> will be created (or recreated) as necessary.
>
> Most people work around this by a strategy like this:
>
> * At logon time, place an attribute into the session under a
> well-known key. The Struts example app uses the User object
> for this purpose.
>
> * At the beginning of each action (or page), check for the
> existence of the well-known attribute. If it is missing,
> this is a new session (possibly a replacement for a timed-out
> one). In the example app, there's an <app:checkLogon> custom
> tag that can do this.
>
> * If a session times out (or is invalidated), all of the attributes
> will be removed. If you want to know when either of these things
> happens, simply make your attribute implement HttpSessionBindingListener
> and it will be notified at timeout or invalidate time.
>
> The servlet 2.3 specification includes new application event listeners for
> session created, session destroyed, and add/change/delete of session
> attributes. Then you'll be able to build apps that react to such events
> without having to involve specific attributes -- but until then we are
> kind of stuck.
>
>
>
> > Andreas
> >
>
> Craig McClanahan
>
Re: Handling session timeouts
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 6 Jun 2001, Andreas Prohaska wrote:
>
> This was originally posted to the struts-user list, but Ted Husted pointed
> out that I should better discuss this on the development list.
>
> For the guys that are not listening to the user list, the background: We
> have written a wizard for a larger input process that requires some steps.
> We use one ActionForm bean for this wizard that keeps the data in the
> session context (everything done by struts). When I wanted to go to the next
> step I recognized that all my data from the previous steps was lost and
> instead I had the default values. Obviously a session timeout occured and
> the original ActionForm was removed. Then a new session was automatically
> created and a new ActionForm bean was automatically added to the session
> context. Normally this is nice, but there was no way for my Action class or
> JSP to see that in fact the session was lost and the data was wrong.
>
> Now I would recommend to place a method like processSession() at the start
> of the process() method in the ActionServlet. This could be changed by
> subclasses of the ActionServlet in order to intercept session creation and
> deprecation. OR it should call some more specialized class for this (say
> SessionManager). The advantage of this approach would be that we could also
> introduce a new <page:init> tag that calls the same class in order to
> intercept session creation in JSP pages (that might be called directly).
>
> If the list decides that this could be nice, I would make the changes but
> then I need to know how I can submit them :-)
>
> What do you think?
>
In servlet 2.2, there is *no* general event handling mechanism that can
catch a session creation no matter where it happened. In order to make
something like this work in Struts, we would have to place restrictions
like this:
* The action cannot call request.getSession() -- it must call some
Struts-provided method that will detect the creation.
* The user cannot *ever* call a JSP page directly, because the session
will be created (or recreated) as necessary.
Most people work around this by a strategy like this:
* At logon time, place an attribute into the session under a
well-known key. The Struts example app uses the User object
for this purpose.
* At the beginning of each action (or page), check for the
existence of the well-known attribute. If it is missing,
this is a new session (possibly a replacement for a timed-out
one). In the example app, there's an <app:checkLogon> custom
tag that can do this.
* If a session times out (or is invalidated), all of the attributes
will be removed. If you want to know when either of these things
happens, simply make your attribute implement HttpSessionBindingListener
and it will be notified at timeout or invalidate time.
The servlet 2.3 specification includes new application event listeners for
session created, session destroyed, and add/change/delete of session
attributes. Then you'll be able to build apps that react to such events
without having to involve specific attributes -- but until then we are
kind of stuck.
> Andreas
>
Craig McClanahan