Jason- the url patterns depends on the servlet mapping you've defined..
You're going to need some algorithm which defines infinity Your current mechanism binds the current Servlet to the ajax control (div?) Acquire the initial date/time ..store it somewhere..hopeully in session when the servlet finally reaches delta greater than *some predefined infinite value* send back result which will cause either the innerhtml to have the requisite logout.jsp or path to logout.jsp return some predefined ActionResult which will *map* to your logout.jsp M- ----- Original Message ----- Wrom: FVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLV To: "'Tomcat Users List'" <users@tomcat.apache.org> Sent: Monday, February 25, 2008 2:29 PM Subject: RE: Session expiration and AJAX issues > > > > -----Original Message----- > > Wrom: LMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHM > > Sent: Monday, February 25, 2008 13:11 > > To: Tomcat Users List > > Subject: Re: Session expiration and AJAX issues > > > > Martin- > > > > We are using Struts, however, version 1.2.9. But, after > > looking at the > > link, I'm not sure this will help as it doesn't really address the > > problem. Storing the date/time a user logs in on the session is > > probably useful, but our problem is that we want to > > forcefully log the > > user out if there's no human present at the computer and the > > AJAX tasks > > keep a user's session active indefinitely, whether or not > > they mean it to. > > > > > > Can url patterns be excluded from session prolonging magic? > > > > > > > > > Additionally, assuming we didn't have the AJAX tasks, we'd > > have to check > > the logged in time from the session on every request and > > that's just not > > realistic when you have hundreds of Struts actions, even with > > a unique > > parent Action class. That said, I'm beginning to suspect > > that this may > > be the only way to go, i.e., have base Action for Struts actions and > > base action for AJAX actions. My only issue with this is > > that then the > > onus is on the developer to use the right Action and if they don't, a > > session could inadvertently be left open which is a security risk. > > > > Alternatively, we could simply force the logout on the user after 12 > > hours period...which would kind of suck for the user if they > > were in the > > middle of something and so I can almost guarantee that our product > > management team wouldn't go for it since it's not really creating a > > positive user experience. > > > > --adam > > > > Martin Gainty wrote: > > > Hi Adam- > > > > > > You can try this with Struts.. > > > http://struts.apache.org/2.x/docs/simplelogin-with-session.html > > > insert the starting-date-time intio Session variable > > > and then in the logoutAction.execute method do some quick > > math on the > > > time-delta to determine if you want to quiesce the session > > > > > > HTH > > > M- > > > > > > ----- Original Message ----- > > > Wrom: KHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONE > > > To: "Tomcat Users List" <users@tomcat.apache.org> > > > Sent: Monday, February 25, 2008 11:04 AM > > > Subject: Session expiration and AJAX issues > > > > > > > > > > > >> A couple of issues: > > >> > > >> We've set our session expiration to 12 hours (I know it's long) and > > >> we're seeing behavior where certain browsers (namely IE) apparently > > >> can't count that high (we set the meta Refresh header but the page > > >> doesn't reload after the allotted time, session expiration > > time + 20 > > >> minutes). > > >> > > >> Since this issue was discovered, we've added background > > AJAX timers on > > >> some of our web pages that refresh (authenticated) > > content. While this > > >> happily works, unfortunately, if the user chooses to > > remain on one of > > >> these pages, and then goes on vacation, the session stays > > active because > > >> the AJAX calls keep the session alive. > > >> > > >> Our first attempt at a solution was to have a JavaScript > > counter that, > > >> after every 20 minutes, incremented a counter and if that > > counter ever > > >> got to 37, we knew that the user hadn't changed web pages > > and we could > > >> log them out (window.location = <logout URL>. The problem > > is that this > > >> doesn't appear to work either and additionally, it relies > > on JavaScript > > >> bypassing Tomcat's built-in features. User's cannot log > > in w/o having > > >> JavaScript enabled, so it's not a matter of a user > > potentially disabling > > >> it, rather it puts the onus on the browser to inform the > > server that the > > >> user's session needs to be expired. > > >> > > >> Does anyone have experience in this area and if so, how > > have you solved > > >> this problem? I know Google uses AJAX with their Gmail > > webapp, but they > > >> don't seem to care about not expiring the user's session. Any help > > >> would be appreciated. > > >> > > >> Thanks, > > >> > > >> --adam > > >> > > >> > > --------------------------------------------------------------------- > > >> To start a new topic, e-mail: users@tomcat.apache.org > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > >> > > > > > > > > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > - - > - Jason Pyeron PD Inc. http://www.pdinc.us - > - Principal Consultant 10 West 24th Street #100 - > - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - > - - > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you > have received it in error, purge the message from your system and > notify the sender immediately. Any other use of the email by you > is prohibited. > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
