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]
