Hi,
This approach would work as well. I just think that if you're going to do
this in struts, it's better to do it in the RequestProcessor. Why?
Assume that you are using the forward action defined in struts. If my
session has timedout and I click on a link that uses the forward action, I
will still see the page. This is because your BaseAction is never called.
On the other hand, if you had checked the request in the
RequestProcessor, I would have been blocked. This is because *ALL*
actions pass through the RequestProcessor... even the struts-defined ones.
That's the approach I would use (RequestProcessor approach) if my
container didn't support filters.
Aladin
> I have a method in my BaseAction called "boolean checkAuth(request)". then
> in every Action I write I code this at the top
>
> // Check if session is active, if not redirect to login page
> if( !checkAuth( request )){
> log.info("*** Session has timed out ***");
> errors.add( ActionErrors.GLOBAL_ERROR, new ActionError("
> error.expired.session") );
> saveErrors(request, errors);
> return
> (mapping.findForward(ApplicationConstants.APP_FORWARD_INVALID_SESSION));
>
> }
>
> seems to work fine.
>
> On 5/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>> Although this approach might work, I don't like it so much. The reasons:
>>
>> 1) Maintainability: if you want to change the timeout to 30 minutes (and
>> you have 50 jsp pages), then you have to make the change 50 times.
>>
>> 2) Business Logic: This approach will never prevent you Action from
>> executing. Since you have to go through an action to reach the jsp page,
>> when the *page* reloads, you are actually reloading the action first.
>> Having said that, if your action does something that should only be
>> executed if your session has not expired, your approach will not work.
>>
>> A combination of using a filter & session-config (in web.xml) solves
>> both
>> problems above. How?
>>
>> 1) You only have to change the session timeout setting in one place.
>>
>> 2) Your filter is executed before anything else. Hence, you never have
>> to
>> worry about an action being executed unintentionally.
>>
>> Aladin
>>
>>
>> > That's easy, just drop this in all of your JSPs (preferrably via an
>> > include
>> > or let a filter do it for you).
>> >
>> > (assuming your session timeout is 20 minutes)
>> >
>> > <meta http-equiv="refresh" content="1200;/">
>> >
>> > You should be handling invalid/expired session state in your
>> application
>> > and
>> > by using the above technique, it will work universally, whether you
>> are
>> > managing sessions from your actions, CMS, or some other service
>> outside
>> of
>> > the conatiner, such as a product like SiteMinder by Netegrity.
>> >
>> > This will _force_ the browser to do a refresh of the page after 1200
>> > seconds
>> > (20 minutes), which will allow your app to handle the request (from a
>> now
>> > expired session) the same as it would if the user had initiated the
>> > request
>> > giving a hint of being on a rich client where such events are easily
>> > handled.
>> >
>> >
>> >
>> >
>> > --
>> > James Mitchell
>> > Software Engineer / Open Source Evangelist
>> > Consulting / Mentoring / Freelance
>> > EdgeTech, Inc.
>> > http://www.edgetechservices.net/
>> > 678.910.8017
>> > AIM: jmitchtx
>> > Yahoo: jmitchtx
>> > MSN: [EMAIL PROTECTED]
>> >
>> >
>> >
>> >
>> > ----- Original Message -----
>> > From: "Adam Lipscombe" <[EMAIL PROTECTED]>
>> > To: "'Struts Users Mailing List'" <user@struts.apache.org>
>> > Sent: Thursday, May 12, 2005 6:19 AM
>> > Subject: Best practice for redirecting on session timeout?
>> >
>> >
>> >> Folks,
>> >>
>> >>
>> >> I there a standard way of handling session timeouts. If a user has
>> been
>> >> inactive for longer than N minutes I want to redirect them to the
>> login
>> >> page.
>> >>
>> >> It occurs to me that this could be done in a) the RequestProcessor or
>> b)
>> >> in
>> >> an JSP include.
>> >>
>> >>
>> >> Is there another way?
>> >> What is best practice?
>> >>
>> >>
>> >> TIA - Adam
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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]
>>
>>
>
>
> --
> -Dave
> [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
