Re: Session expiration and AJAX issues
Not easily. See Christopher's response in this thread chain. There is not currently a way to not tell Tomcat that a request has come in and not update the last ping time (or similar) on the Session. Jason Pyeron wrote: -Original Message- From: Adam Gordon [mailto:[EMAIL PROTECTED] 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 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session expiration and AJAX issues
Hi, 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). Are you saying that certain browser will never expire their sessions? Or are you saying that certain browsers kill their sessions before 12 hours (because they can't count that high)? 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. The way I understand it - you are using ajax to keep a session alive. Why not set the session expiration to live as long as the browser is open, or for some other length of time? The session mechanism should work. I don't understand the need to hack sessions using ajax. it puts the onus on the browser to inform the server that the user's session needs to be expired. Isn't that part of the browser's job? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session expiration and AJAX issues
Paul- Are you saying that certain browser will never expire their sessions? Or are you saying that certain browsers kill their sessions before 12 hours (because they can't count that high)? The former, i.e. that browsers will never expire the sessions. The way I understand it - you are using ajax to keep a session alive. Why not set the session expiration to live as long as the browser is open, or for some other length of time? The session mechanism should work. I don't understand the need to hack sessions using ajax. As indicated from the tone of my original post (see the second sentence of the second paragraph in my original post), are not intentionally using AJAX to keep the session alive - it is a side-effect which we would like to obviate, hence the JavaScript counter. Isn't that part of the browser's job? Uh, I would have to argue that this is a HUGE no. I think it's VERY obvious to anyone that has done any sort of web development with cross-browser compatibility in mind that browser makers cannot be relied upon to implement ANY sort of common standard in the same way (case and point look at how you instantiate an XmlHttpRequest object in JavaScript across different browsers, not to mention CSS functionality). Besides if it were the browser's job, why would Tomcat even have support for it? It's like making an assumption that user's never leave their browsers open or never click the back button. I think the only thing one can absolutely rely on a user doing in a web application using it in a manner to which one had not considered. So, all that said, is there anyone out there who's had experience with this problem and knows of a solution? 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]
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. 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 [EMAIL PROTECTED] 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]
Re: Session expiration and AJAX issues
--- 10:10AM Mon 25 Feb 2008, Adam Gordon [EMAIL PROTECTED] wrote: 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. If there's a user input side to the AJAX tasks, would it be possible for the AJAX task time interval to increase over time w/o user input? Eventually, this would lead to a session timeout. -Bob Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session expiration and AJAX issues
-Original Message- From: Adam Gordon [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 x333Baltimore, 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
Re: Session expiration and AJAX issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adam,
What you need is to make a request without touching the session.
Tomcat cannot do this by itself; you're going to have to either hack
Tomcat to add a no-touch-session parameter to the session manager
(which wouldn't be a bad TC enhancement request, actually), or pass your
session information in a different way through your AJAX calls (say,
using mysessionid as a request parameter, and be sure that the
JSESSIONID cookie is /not/ sent - which might be quite difficult).
The second option is rife with complexity, because then you need to have
your server-side AJAX stuff take the session id and look it up in a
self-managed cache of sessions (see HttpSessionListener), etc., etc., etc.
Here's another option that might not be /quite/ as nasty, but it's still
a pretty bad hack:
1. Invent a new request parameter called noTouchSession and add
~ noTouchSession=true to all of your AJAX calls.
2. Write a Filter that looks something like this:
public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain chain)
{
~HttpServletRequest hReq = (HttpServletRequest)req;
~HttpSession session = hReq.getSession(false);
~if(null != session)
~{
~Date expirationDate =
~ (Date)session.getAttribute(expirationDate);
~if(expirationDate.before(new Date())
~{
~// probably want to log this event
~session.invalidate();
~session=null;
~}
~else
~{
~if(true.equalsIgnoreCase(hReq.getParameter(noTouchSession)))
~{
~// Do nothing; don't update the session timestamp
~}
~else
~{
~session.setAttribute(expirationDate,
~ new Date(System.currentTimeMillis() +
~session.getMaxInactiveInterval() / 1000));
~}
~}
~}
~chain.doFilter(req, resp);
}
What this will do is essentially simulate session timeouts using an
attribute /you/ store in the session instead of relying on the
container. The container will still do all the real work of session
management, which is nice.
Since your AJAX requests will add the magic parameter that doesn't touch
the session timeout, your session will eventually time out (using this
mechanism, not that of the container).
Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfDJY0ACgkQ9CaO5/Lv0PB/7gCdFap7ZW3RZNxrlewwBmtNtwpH
Yr0AoKdYyaGjZkWzUtORawePA+xOFTlX
=uSL3
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session expiration and AJAX issues
Adding a time decay in our timer task is an interesting idea and were it not for IE's JavaScript counting ineptness, that'd probably work. Bob Hall wrote: --- 10:10AM Mon 25 Feb 2008, Adam Gordon [EMAIL PROTECTED] wrote: 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. If there's a user input side to the AJAX tasks, would it be possible for the AJAX task time interval to increase over time w/o user input? Eventually, this would lead to a session timeout. -Bob Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ - 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]
Re: Session expiration and AJAX issues
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
Re: Session expiration and AJAX issues
--- 2:09PM Mon 25 Feb 2008 Adam Gordon [EMAIL PROTECTED] wrote: Adding a time decay in our timer task is an interesting idea and were it not for IE's JavaScript counting ineptness, that'd probably work. The server could track the requests and provide an updated delay time for the timer task if the browser isn't reliable. -Bob Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
