Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
From: "Jason Pyeron" <jpyeron@pdinc.us>
To: "'Tomcat Users List'" <users@tomcat.apache.org>
Subject: RE: Session expiration and AJAX issues
Date: Mon, 25 Feb 2008 14:29:13 -0500
Organization: PD Inc
Message-ID: <008401c877e4$b4418220$6a01a8c0@MRSLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Ach32d0IiK2aGf0aTFCj3Xv6BLN9UQACrylA
In-Reply-To: <47C304AF.7060500@readytalk.com>

 
> -----Original Message-----
> From: Adam Gordon [mailto:adam.gordon@readytalk.com] 
> 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 -----
> > From: "Adam Gordon" <adam.gordon@readytalk.com>
> > 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: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >>     
> >
> >   
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org