You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Sharon Prober (sprober)" <sp...@cisco.com> on 2011/11/09 09:56:13 UTC

Session time out never takes place with ajax

Hi,

 

This is my first post here so wish me luck J

 

My question is as follow:

I have a web based application running on tomcat 6.0.29

On my main page there is a polling ajax call every 5 seconds.

Clearly this revalidates the session and by that renders the session
timeout feature unusable

 

I read about two main solutions for this issue

1.       Coding on the server side (filter) a simple snippet that
identifies an ajax call based on a parameter passed and based on that
knows if this is a valid post or a polling hit that should not affect
the session expiration date

2.       Create a stub webapp and redirect the calls of the polling to
that app

 

So my question is, is there another way for this to be achieved?

 

Note. I think it might be a cool feature (with the vast ajax use these
days) to have a configuration in the web.xml the excludes various
paths/urls from the session validation checkups

Something like

 

<session-config>

                                <session-timeout>30</session-timeout>

                                <ignore>path1,path2.....</ignore>

</session-config>

 

Thanks,

                Sharon


RE: Session time out never takes place with ajax

Posted by "Sharon Prober (sprober)" <sp...@cisco.com>.
Ok,

Thanks all for the inputs. I found a hybrid solution for this.
So for future use here goes....

In my application I make sure there is a filter that is called on every hit to the server "/*"
Next I create a new filter which will handle only calls such as poling and other ajax calls that do not "postpone" the expiration date of the session.
In the web.xml I can use the <url-pattern> element as a framework hook for each developer in the application to enter their own "poling" link

The way it works is as follows
1)SessionTimeoutFilter doFilter ....
public void doFilter(ServletRequest request, ServletResponse response,
			FilterChain filterChain) throws IOException, ServletException {
		HttpServletRequest req = (HttpServletRequest) request;

		HttpSession session = req.getSession(false);
		if (null != session) {
			Date realLastAccessDate = (Date) session
					.getAttribute(SESSION_LAST_ACCESS_IDENTIFIER);
			if (realLastAccessDate == null) {
				realLastAccessDate = new Date();
				session.setAttribute(SESSION_LAST_ACCESS_IDENTIFIER, realLastAccessDate);
			}
			if (realLastAccessDate.before(new Date())) {
				// probably want to log this event
				session.invalidate();
				session = null;
			}

		}
		request.setAttribute(IS_SESSION_TIMEOUT_RESETER,false);
		filterChain.doFilter(request, response);

	}

2)The general filter that is always called...
public void doFilter(ServletRequest request, ServletResponse response,
			FilterChain filterChain) throws IOException, ServletException {
	HttpSession session = hreq.getSession(false);
		if(session!=null && 
				(hreq.getAttribute(SessionTimeoutFilter.IS_SESSION_TIMEOUT_RESETER)==null ||
					 ((Boolean)hreq.getAttribute(SessionTimeoutFilter.IS_SESSION_TIMEOUT_RESETER)).booleanValue())){
            Date expirationDate = new Date(System.currentTimeMillis() + 
                    session.getMaxInactiveInterval()/*seconds*/  * 1000 /*milliseconds*/);

			session.setAttribute(SessionTimeoutFilter.SESSION_LAST_ACCESS_IDENTIFIER, expirationDate);
		}
		
		chain.doFilter(request, response);
}

3) the web.xml... (make sure it’s a the first filter defined!)
    <filter>
         <filter-name>SessionTimeoutFilter</filter-name>
         <filter-class>(the package)SessionTimeoutFilter</filter-class>
        
   </filter>
    <filter-mapping>
        <filter-name>SessionTimeoutFilter</filter-name>
        <url-pattern>/YOUR-URL-PATTERN</url-pattern>
     	 <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher>
        <dispatcher>INCLUDE</dispatcher>
    </filter-mapping>


From this point on any developer can add url patterns that will not postpone the expiration date simply by adding
<url-pattern>/YOUR-OTHER-URL-PATTERN</url-pattern>

HTH anyone,
	Sharon

-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net] 
Sent: Monday, November 14, 2011 6:17 PM
To: Tomcat Users List
Subject: Re: Session time out never takes place with ajax

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sharon,

On 11/10/11 3:11 AM, Sharon Prober (sprober) wrote:
> I understand it is invoked before the filters, but after
> completion it would arrive to the filter/servlet container anyway.
> So what your saying is that if I build a valve and read information
> from IO file or/db or any other cached data which doesn’t trigger
> a request.getSession That will work?

I think it would help if you explained what your "ping" needs to do.
Basically, if you need session data to do it, you are out of luck. If
you don't need session data, why are you pinging?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7BPvIACgkQ9CaO5/Lv0PD6rQCglhRD4lA4qMaqkybwBXvjeqc1
+LIAn3ARzOKhsdzPqBJ9xkkLYAeIWiXf
=kM6R
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Session time out never takes place with ajax

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sharon,

On 11/10/11 3:11 AM, Sharon Prober (sprober) wrote:
> I understand it is invoked before the filters, but after
> completion it would arrive to the filter/servlet container anyway.
> So what your saying is that if I build a valve and read information
> from IO file or/db or any other cached data which doesn’t trigger
> a request.getSession That will work?

I think it would help if you explained what your "ping" needs to do.
Basically, if you need session data to do it, you are out of luck. If
you don't need session data, why are you pinging?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7BPvIACgkQ9CaO5/Lv0PD6rQCglhRD4lA4qMaqkybwBXvjeqc1
+LIAn3ARzOKhsdzPqBJ9xkkLYAeIWiXf
=kM6R
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Session time out never takes place with ajax

Posted by chris derham <ch...@derham.me.uk>.
>
> So to recap, and verify my understanding...
> Perhaps I am missing some valve overview.
>
> I understand it is invoked before the filters, but after completion it
> would arrive to the filter/servlet container anyway.
> So what your saying is that if I build a valve and read information from
> IO file or/db or any other cached data which doesn’t trigger a
> request.getSession
> That will work?
> And if so, I will still need to "break" the chain and prevent it from
> continuing deeper into tomcat or else it will update the session access time
>
> Instead of mapping all requests e.g. /* through security*, you could split
you app. So say /public folder contains static resources and requires not
security*. You could put dynamic resources under /dynamic and map to
security*. That way anybody requesting a dynamic resource would need a
session, and this would be touched on every request to /dynamic/*. If you
had this kind of setup, then you could create another top level folder
called say /ajaxPing and not map that to security*. Then as long as the
filter/servlet/jsp page that fulfills that request does not call
request.getSession, you will fulfill your aim to respond without affecting
session expiration

Alternatively you could put a valve in the front of the whole web app, and
have that respond to a given url, and then stop the request, e.g. not pass
the request to tomcat. I beleive that is what Mr Schultz was suggesting

* when I keep saying security, I'm not sure the correct collective term. I
don't just mean container security, but also any filter/servlet/jsp that
calls request.getSession

HTH

Chris

RE: Session time out never takes place with ajax

Posted by "Sharon Prober (sprober)" <sp...@cisco.com>.
Christopher,

So to recap, and verify my understanding...
Perhaps I am missing some valve overview.

I understand it is invoked before the filters, but after completion it would arrive to the filter/servlet container anyway.
So what your saying is that if I build a valve and read information from IO file or/db or any other cached data which doesn’t trigger a request.getSession
That will work?
And if so, I will still need to "break" the chain and prevent it from continuing deeper into tomcat or else it will update the session access time

Did I get it right?

	Sharon

-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net] 
Sent: Thursday, November 10, 2011 8:04 AM
To: Tomcat Users List 
Subject: Re: Session time out never takes place with ajax

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sharon,

On 11/9/11 12:56 AM, Sharon Prober (sprober) wrote:
> This is my first post here so wish me luck J

Welcome.

> My question is as follow:
> 
> I have a web based application running on tomcat 6.0.29
> 
> On my main page there is a polling ajax call every 5 seconds.
> 
> Clearly this revalidates the session and by that renders the
> session timeout feature unusable

Yes.

> I read about two main solutions for this issue
> 
> 1.       Coding on the server side (filter) a simple snippet that 
> identifies an ajax call based on a parameter passed and based on
> that knows if this is a valid post or a polling hit that should not
> affect the session expiration date

This is problematic for a few reasons:

1. You usually want a polling request to return something of use, which
   often involves the session. You can't access the session without
   updating its last-accessed-time.

2. Under certain configuration, Tomcat will update the
   last-accessed-time of the session even if you don't call
   request.getSession().

   This may be only the case in Tomcat 7 with the following
   configuration settings:

   See the org.apache.catalina.core. StandardHostValve.ACCESS_SESSION
   and org.apache.catalina.STRICT_SERVLET_COMPLIANCE system properties
   here:
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Sessions

> 2.       Create a stub webapp and redirect the calls of the polling
> to that app

I'm not sure this buys you anything: if you pass-through calls to the
"real" webapp, then you'll still be touching the session.

> So my question is, is there another way for this to be achieved?

It would be best to describe what your "ping" actually does. If it
doesn't require session access, you may have some options.

> Note. I think it might be a cool feature (with the vast ajax use
> these days) to have a configuration in the web.xml the excludes
> various paths/urls from the session validation checkups

This would, by definition, be a violation of the specification.
Instead, something like a Valve placed early in the pipeline could
avoid a session update but still perform some trivial action.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk67aUkACgkQ9CaO5/Lv0PBl2ACdHDKUqQ/zkT0dfc63MFELStLK
+a4An3kuFz39fXKymLVFBqYRMQ9xWUbX
=naid
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Session time out never takes place with ajax

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sharon,

On 11/9/11 12:56 AM, Sharon Prober (sprober) wrote:
> This is my first post here so wish me luck J

Welcome.

> My question is as follow:
> 
> I have a web based application running on tomcat 6.0.29
> 
> On my main page there is a polling ajax call every 5 seconds.
> 
> Clearly this revalidates the session and by that renders the
> session timeout feature unusable

Yes.

> I read about two main solutions for this issue
> 
> 1.       Coding on the server side (filter) a simple snippet that 
> identifies an ajax call based on a parameter passed and based on
> that knows if this is a valid post or a polling hit that should not
> affect the session expiration date

This is problematic for a few reasons:

1. You usually want a polling request to return something of use, which
   often involves the session. You can't access the session without
   updating its last-accessed-time.

2. Under certain configuration, Tomcat will update the
   last-accessed-time of the session even if you don't call
   request.getSession().

   This may be only the case in Tomcat 7 with the following
   configuration settings:

   See the org.apache.catalina.core. StandardHostValve.ACCESS_SESSION
   and org.apache.catalina.STRICT_SERVLET_COMPLIANCE system properties
   here:
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Sessions

> 2.       Create a stub webapp and redirect the calls of the polling
> to that app

I'm not sure this buys you anything: if you pass-through calls to the
"real" webapp, then you'll still be touching the session.

> So my question is, is there another way for this to be achieved?

It would be best to describe what your "ping" actually does. If it
doesn't require session access, you may have some options.

> Note. I think it might be a cool feature (with the vast ajax use
> these days) to have a configuration in the web.xml the excludes
> various paths/urls from the session validation checkups

This would, by definition, be a violation of the specification.
Instead, something like a Valve placed early in the pipeline could
avoid a session update but still perform some trivial action.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk67aUkACgkQ9CaO5/Lv0PBl2ACdHDKUqQ/zkT0dfc63MFELStLK
+a4An3kuFz39fXKymLVFBqYRMQ9xWUbX
=naid
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org