Good point Aladin... However, I would take this a step further...
in pre-1.3 Struts, you might not want to implement your own RP for various reasons, so I would suggest doing this in a filter instead... Same benefit as modifying the RP, but doesn't touch Struts code and is also more portable... should you ever want to not use Struts for some reason, you don't have to worry about re-implementing your auth check. In 1.3, you could probably make a good argument for modifying the RP chain, certainly that's what your meant to be able to do!, but I think the same good reasons for using a filter would still apply there. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, May 12, 2005 10:57 am, [EMAIL PROTECTED] said: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
