Sorry, I lost track of the thread (stupid webmail interface!)... can you outline your method again?
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, May 12, 2005 1:39 pm, David Johnson said: > So, how what would you all say about my method? does this seem to be a > valid > method for controlling this? > > On 5/12/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> >> 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] >> >> > > > -- > -Dave > [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
