You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Josh Simmons <Jo...@colinx.com> on 2011/07/13 20:14:42 UTC
Session cookie max age
Hello,
We have recently upgraded our tomcats to Tomcat7 in order to gain the new exposure to the configuration of the session cookie, namely the max age property. I had tried reading posts about getting it to work with tomcat6 but writing multiple cookies to the request caused problems for quite a few of our end users.
We tried to set the cookie max age to 3 hours, the exact same time as our session timeout. However, I was extremely surprised that the session cookie didn't get updated on every request. The cookie max age was set when the session was created and that was it. The end result is that our users who stay signed on for longer than 3 hours now appear to get logged out.
I'm curious about this functionality - why was the decision made to not update the session cookie if a max age is set? We can effectively get what we want by setting the max age to 24 hours, but that seems like the wrong solution.
Any help on the matter is greatly appreciated.
Joshua Simmons
RE: Session cookie max age
Posted by Josh Simmons <Jo...@colinx.com>.
Thanks for the info on the doctype, I will look into that.
Version information:
Server version: Apache Tomcat/7.0.14
Server built: May 9 2011 10:40:56
Server number: 7.0.14.0
For your issue #1, that's the entire reason I was asking. Since its a session cookie I was curious as to why the max age isn't updated to reflect the current state of the session.
-----Original Message-----
From: Konstantin Kolinko [mailto:knst.kolinko@gmail.com]
Sent: Wednesday, July 13, 2011 8:55 PM
To: Tomcat Users List
Subject: Re: Session cookie max age
2011/7/14 Josh Simmons <Jo...@colinx.com>:
> Our web.xml file minus listeners and servlet config. I also removed some taglib definitions.
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
>
> <!DOCTYPE web-app
> PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd">
Eh... remove the above. It isn't servlet 2.3 webapp, isn't it?
>
> <web-app xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
> version="3.0">
If you'll add the following line into conf/catalina.properties, Tomcat will validate your web.xml file according to the schema:
org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
[http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html]
You are not saying what release of Tomcat 7.0.x you are using.
AFAIK,
1) Tomcat won't send Set-Cookie when session id is already known (either from this webapp or from webapp on its parent path such as ROOT).
See code that calls
o.a.c.core.ApplicationSessionCookieConfig#createSessionCookie(..)
2) The Cookie header sent by the web browser does not include neither Path nor Expires/Max-Age values.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session cookie max age
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Konstantin,
On 7/14/2011 10:53 AM, Christopher Schultz wrote:
> On 7/14/2011 10:40 AM, Konstantin Kolinko wrote:
>>
>> I cannot say without reading the letter of the spec.
>
> I'll take a look.
Servlet 3.0 section 14.4.10 is the only place I can see that
cookie-config is mentioned at all. Unfortunately, it's shown in an image
and therefore not findable using text search. :( It doesn't show that
cookie-config has any sub-elements, either (just that they exist, it
just doesn't show them).
So, we have to turn to the XML Schema documentation for the element.
The parent schema, http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd,
says nothing because the definitions come from
http://java.sun.com/xml/ns/javaee/web-common_3_0.xsd, where
cookie-config is defined along with it's sub elements, including <max-age>:
<xsd:element name="max-age"
type="javaee:xsdIntegerType"
minOccurs="0">
<xsd:annotation>
<xsd:documentation>
The lifetime (in seconds) that will be assigned to any
session tracking cookies created by this web application.
Default is -1
</xsd:documentation>
</xsd:annotation>
</xsd:element>
That's pretty much all we have to go on.
Since it's a cookie property, the server has no control over it after
the initial Set-Cookie response header. That is, the client controls the
actual expiration of the cookie as it sees fit.
java/org/apache/catalina/connector/Request.doGetSession (and, later,
java/org/apache/catalina/connector/Request.changeSessionId) are
responsible for actually creating the session cookies and then adding
them to the response.
I don't see any logic in there for checking the max-age and re-sending
the cookie to update the client.
The question, though, is what is the intent of the setting? There are
two ways to interpret <cookie-config><max-age>:
1. The value is used to set an absolute maximum age of the cookie,
relative to the creation of the session. The cookie expires after
that, and the session is effectively lost after that. The semantics
here are of a server session with a client-enforced expiration
some fixed time in the future, regardless of how recently the
user visited the server.
2. The value is used to set a sliding maximum age of the cookie,
essentially mirroring the server-side behavior with a client-enforced
session expiration (by proxy via the cookie).
#1 seems like it could be useful if you wanted a hard-maximum on the
length of the session, like "in 10 hours, you're done no matter what".
#2 seems like it solves a historically spec-ignored situation: allowing
cookie-based sessions to survive a browser restart. When using URL
rewriting, the session only expires if the server says it does, and this
allows cookie-based session tracking to enjoy the same benefits.
If #2 is the intended behavior, then this is a bug in Tomcat.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4gU5MACgkQ9CaO5/Lv0PAoAACfW3jw8bcuaUze4b2+EtEUP6eV
PU0An0tSpjNAz2zKnTwY56vFHj16AE2x
=ZpJv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session cookie max age
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Konstantin,
On 7/14/2011 10:40 AM, Konstantin Kolinko wrote:
> 2011/7/14 Christopher Schultz <ch...@christopherschultz.net>:
>>
>> Konstantin,
>>
>> On 7/13/2011 8:54 PM, Konstantin Kolinko wrote:
>>> AFAIK, 1) Tomcat won't send Set-Cookie when session id is
>>> already known (either from this webapp or from webapp on its
>>> parent path such as ROOT).
>>
>> That would sound like a bug. If the session cookie's expiration
>> date is not "-1", then it needs to be updated with every response,
>> no?
>
> I cannot say without reading the letter of the spec.
+1
I'll take a look.
- From reading the docs for <max-age> in web.xml's Schema, it looks like
the max-age is essentially a client-enforced session timeout... this
allows (as the OP wants) sessions on the client to survive client restarts.
> 1) Updating it with every response sounds lame.
I'm not sure there's any other way to do it (if my interpretation of the
above is correct). A cookie has an expiration date, and that expiration
date needs to be nudged further into the future every time the session
is accessed.
> 2) max-age value should be consistent between all web applications
> that might share the session cookie. Otherwise there will be
> inconsistencies and breakages.
The spec doesn't cover SSO, so I think it's likely that this case isn't
covered there.
> 3) I think that there might be use case when max age is greater than
> zero, but app owner does not want to send it with each response.
In these case, max-age is always greater than zero. Under what cases
would an app owner have max-age > 0 but also not want to sent with every
response?
> Is SSO cookie updated with each response?
Dunno. Probably max-age=-1 for those. I'll check.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4fAs8ACgkQ9CaO5/Lv0PBVUgCgi11MP6d5FK/5g55V2paQ1sIu
H8oAoLwKs4f+ApX0O6y72hn+Un19Pd2i
=etqa
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session cookie max age
Posted by Pid <pi...@pidster.com>.
On 14/07/2011 15:54, André Warnier wrote:
> Konstantin Kolinko wrote:
> ...
>>
>> 1) Updating it with every response sounds lame.
>>
>> 2) max-age value should be consistent between all web applications
>> that might share the session cookie.
>> Otherwise there will be inconsistencies and breakages.
>>
> Are you not confusing "max-age" with "last access" ?
Possibly the confusion* is that:
http://download.oracle.com/javaee/5/api/javax/servlet/http/Cookie.html
defines setMaxAge() but one could infer that it should be persisted and
a rolling value applied on each request, but it actually maps to the
Expires attribute of the cookie.
I suppose the method name is misleading, semantically better to have
said "setExpires(long)" instead.
p
* It's confused me, certainly.
** Ooh look at me doing an André, quoting HTTP specs
> The expiration of a cookie (like the expiration of a session), in my
> view should be calculated on the base of :
> last access + max-age, compared to "now"
>
> And then, there is the question of whether "last access" should be
> updated when the request is received, or when the response is sent.
> (Apparently the Servlet Spec has things to say on the matter, and some
> recently added Tomcat properties also).
>
> There was another thread recently debating similar issues, in the
> context of long file upload requests.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Session cookie max age
Posted by André Warnier <aw...@ice-sa.com>.
Konstantin Kolinko wrote:
...
>
> 1) Updating it with every response sounds lame.
>
> 2) max-age value should be consistent between all web applications
> that might share the session cookie.
> Otherwise there will be inconsistencies and breakages.
>
Are you not confusing "max-age" with "last access" ?
The expiration of a cookie (like the expiration of a session), in my view should be
calculated on the base of :
last access + max-age, compared to "now"
And then, there is the question of whether "last access" should be updated when the
request is received, or when the response is sent.
(Apparently the Servlet Spec has things to say on the matter, and some recently added
Tomcat properties also).
There was another thread recently debating similar issues, in the context of long file
upload requests.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session cookie max age
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/7/14 Christopher Schultz <ch...@christopherschultz.net>:
>
> Konstantin,
>
> On 7/13/2011 8:54 PM, Konstantin Kolinko wrote:
>> AFAIK, 1) Tomcat won't send Set-Cookie when session id is already
>> known (either from this webapp or from webapp on its parent path
>> such as ROOT).
>
> That would sound like a bug. If the session cookie's expiration date is
> not "-1", then it needs to be updated with every response, no?
I cannot say without reading the letter of the spec.
1) Updating it with every response sounds lame.
2) max-age value should be consistent between all web applications
that might share the session cookie.
Otherwise there will be inconsistencies and breakages.
3) I think that there might be use case when max age is greater than
zero, but app owner does not want to send it with each response.
Is SSO cookie updated with each response?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session cookie max age
Posted by Pid <pi...@pidster.com>.
On 14/07/2011 15:27, Christopher Schultz wrote:
> Konstantin,
>
> On 7/13/2011 8:54 PM, Konstantin Kolinko wrote:
>> AFAIK, 1) Tomcat won't send Set-Cookie when session id is already
>> known (either from this webapp or from webapp on its parent path
>> such as ROOT).
>
> That would sound like a bug. If the session cookie's expiration date is
> not "-1", then it needs to be updated with every response, no?
Ahh, the ever popular cookie debate.
Servlet 2.5 doesn't list RFC 2965 as a 'relevant' specification, but
that does offer the Max-Age attribute of the Cookie header value.
http://tools.ietf.org/html/rfc2965
If this was being written in the response, then the cookie header does
not need to be set on each request.
p
(Disclaimer, smallprint, browser support, yes, etc etc.)
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Session cookie max age
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Konstantin,
On 7/13/2011 8:54 PM, Konstantin Kolinko wrote:
> AFAIK, 1) Tomcat won't send Set-Cookie when session id is already
> known (either from this webapp or from webapp on its parent path
> such as ROOT).
That would sound like a bug. If the session cookie's expiration date is
not "-1", then it needs to be updated with every response, no?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4e/OkACgkQ9CaO5/Lv0PB4dQCfbDGqkJiZyIZI59PaQtCx3wY8
lawAmwQvEr5YdXStxsNwEW8E1JeYCuMD
=HSIJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session cookie max age
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/7/14 Josh Simmons <Jo...@colinx.com>:
> Our web.xml file minus listeners and servlet config. I also removed some taglib definitions.
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
>
> <!DOCTYPE web-app
> PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd">
Eh... remove the above. It isn't servlet 2.3 webapp, isn't it?
>
> <web-app xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
> version="3.0">
If you'll add the following line into conf/catalina.properties, Tomcat
will validate your web.xml file according to the schema:
org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
[http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html]
You are not saying what release of Tomcat 7.0.x you are using.
AFAIK,
1) Tomcat won't send Set-Cookie when session id is already known
(either from this webapp or from webapp on its parent path such as
ROOT).
See code that calls
o.a.c.core.ApplicationSessionCookieConfig#createSessionCookie(..)
2) The Cookie header sent by the web browser does not include neither
Path nor Expires/Max-Age values.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Session cookie max age
Posted by Josh Simmons <Jo...@colinx.com>.
Our web.xml file minus listeners and servlet config. I also removed some taglib definitions.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<distributable/>
<context-param>
<param-name>org.apache.taglibs.standard.lang.jstl.exprCacheSize</param-name>
<param-value>100</param-value>
</context-param>
<filter>
<filter-name>Performance Log Filter</filter-name>
<filter-class>ourCompanyPath.PerfLogServletFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Performance Log Filter</filter-name>
<url-pattern>/do/*</url-pattern>
</filter-mapping>
<filter>
<filter-name>Encoding</filter-name>
<filter-class>ourCompanyPath.EncodingFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Encoding</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<!-- the session should last 180 min. -->
<session-config>
<session-timeout>180</session-timeout>
<cookie-config>
<max-age>
10800
</max-age>
</cookie-config>
</session-config>
<!-- The Usual Welcome File List -->
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
**************
The problem with the filter you are speaking of is that it actually adds multiple cookies to the request. While most people say that they haven't found this to cause problems - we actually did find that it caused users problems. Firefox accepts the last cookie sent, but I've found reports saying that IE accepts the first cookie. I'm not really sure what was going on, but the patterns were extremely inconsistent and hard to replicate. All I know is that we had people turn off cookies completely on our website and things started working again. That was the reason we upgraded to tomcat7 in the first place.
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Wednesday, July 13, 2011 5:43 PM
To: Tomcat Users List
Subject: Re: Session cookie max age
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Josh,
On 7/13/2011 5:15 PM, Josh Simmons wrote:
> I was afraid I wasn't being specific enough - sorry.
>
> <session-config> <session-timeout>180</session-timeout>
> <cookie-config> <max-age> 10800 </max-age> </cookie-config>
> </session-config>
Can you post your entire web.xml? You can remove all the servlet, listener, and security constraint stuff.
> We do not want to use the default cookie max age of -1 for our session
> cookie. We would like for our session to persist across browser
> restart (I know this might be frowned upon but it’s a stepping stone
> towards the correct solution) - so in order to do so we set the max
> age of our session cookie to 3hours , the same as our timeout.
Gotcha.
> While the jsessionid might not be changing for every request, the
> timeout is changing with every request.
Okay, now I get it. You expect Tomcat to set the cookie's max age to be NOW + 180 minutes. That's what I'd expect, too.
> As I stated previously, we can fix this by just configuring our max
> age to be 24 hours, because ideally no one is going to perfectly keep
> their session alive on the server for that length of time.
>
> Hopefully this makes more sense now of what I'm after.
It does. Assuming that you don't have a misconfiguration and that this is a Tomcat bug, you ought to be able to get around the problem using a Filter that looks something like this:
public class SessionCookieMaxAgeFilter
implements Filter
{
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
{
if(request instanceof HttpServletRequest)
{
Cookie cookie = getCookie((HttpServletRequest)request));
if(null != cookie)
{
// force the cookie back on the client
cookie.setMaxAge(180);
((HttpServletResponse)response).addCookie(cookie);
}
}
}
private Cookie getCookie(HttpServletRequest request)
{
Cookie[] cookies = request.getCookies();
if(null != cookies)
{
for(int i=0; i<cookies.length; ++i)
{
if("JSESSIONID".equals(cookies[i].getName()))
{
return cookie;
}
}
}
return null;
}
}
Post your configuration and I'll take a look at the code (which may take some time :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4eEUgACgkQ9CaO5/Lv0PAH5gCfTJijKQNqLv3F/TPQVT9CCMCL
RiMAn2b/CDEJj+vPQrRFj5FozSATkst/
=i8JZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session cookie max age
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Josh,
On 7/13/2011 5:15 PM, Josh Simmons wrote:
> I was afraid I wasn't being specific enough - sorry.
>
> <session-config> <session-timeout>180</session-timeout>
> <cookie-config> <max-age> 10800 </max-age> </cookie-config>
> </session-config>
Can you post your entire web.xml? You can remove all the servlet,
listener, and security constraint stuff.
> We do not want to use the default cookie max age of -1 for our
> session cookie. We would like for our session to persist across
> browser restart (I know this might be frowned upon but it’s a
> stepping stone towards the correct solution) - so in order to do so
> we set the max age of our session cookie to 3hours , the same as our
> timeout.
Gotcha.
> While the jsessionid might not be changing for every request, the
> timeout is changing with every request.
Okay, now I get it. You expect Tomcat to set the cookie's max age to be
NOW + 180 minutes. That's what I'd expect, too.
> As I stated previously, we can fix this by just configuring our max
> age to be 24 hours, because ideally no one is going to perfectly
> keep their session alive on the server for that length of time.
>
> Hopefully this makes more sense now of what I'm after.
It does. Assuming that you don't have a misconfiguration and that this
is a Tomcat bug, you ought to be able to get around the problem using a
Filter that looks something like this:
public class SessionCookieMaxAgeFilter
implements Filter
{
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
{
if(request instanceof HttpServletRequest)
{
Cookie cookie = getCookie((HttpServletRequest)request));
if(null != cookie)
{
// force the cookie back on the client
cookie.setMaxAge(180);
((HttpServletResponse)response).addCookie(cookie);
}
}
}
private Cookie getCookie(HttpServletRequest request)
{
Cookie[] cookies = request.getCookies();
if(null != cookies)
{
for(int i=0; i<cookies.length; ++i)
{
if("JSESSIONID".equals(cookies[i].getName()))
{
return cookie;
}
}
}
return null;
}
}
Post your configuration and I'll take a look at the code (which may take
some time :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4eEUgACgkQ9CaO5/Lv0PAH5gCfTJijKQNqLv3F/TPQVT9CCMCL
RiMAn2b/CDEJj+vPQrRFj5FozSATkst/
=i8JZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Session cookie max age
Posted by Josh Simmons <Jo...@colinx.com>.
I was afraid I wasn't being specific enough - sorry.
<session-config>
<session-timeout>180</session-timeout>
<cookie-config>
<max-age>
10800
</max-age>
</cookie-config>
</session-config>
We do not want to use the default cookie max age of -1 for our session cookie. We would like for our session to persist across browser restart (I know this might be frowned upon but it’s a stepping stone towards the correct solution) - so in order to do so we set the max age of our session cookie to 3hours , the same as our timeout.
While the jsessionid might not be changing for every request, the timeout is changing with every request. The max age of the cookie does not however change to reflect this information. Really what would be desirable for configuring the cookie would be something like the expires type configuration: access plus 3hrs.
As I stated previously, we can fix this by just configuring our max age to be 24 hours, because ideally no one is going to perfectly keep their session alive on the server for that length of time.
Hopefully this makes more sense now of what I'm after.
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Wednesday, July 13, 2011 3:01 PM
To: Tomcat Users List
Subject: Re: Session cookie max age
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Josh,
On 7/13/2011 2:14 PM, Josh Simmons wrote:
> We tried to set the cookie max age to 3 hours, the exact same time as
> our session timeout.
So, this is a non-session cookie?
> However, I was extremely surprised that the session cookie didn't get
> updated on every request.
Why should it? The information does not change with every request.
> The cookie max age was set when the session was created and that was
> it.
Okay.
> The end result is that our users who stay signed on for longer than
> 3 hours now appear to get logged out.
Is that because your non-session cookie is somehow expected to interact with the session cookie?
If a user goes 3 hours without any activity, the session expires.
JSESSIONID cookies are, by default, temporary cookies for the user agent
(browser) and do not have an expiration date (that is, they expire when the browser shuts down). It's up to Tomcat to determine the expiration time of the actual HTTP session.
> I'm curious about this functionality - why was the decision made to
> not update the session cookie if a max age is set? We can effectively
> get what we want by setting the max age to 24 hours, but that seems
> like the wrong solution.
Can you show your configuration and/or code that is relevant?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4d62wACgkQ9CaO5/Lv0PAkPACfU5RRFYpswrZUk/vfEQqJfukL
HBUAn1/xJVprK2PwBd6iEHobVrwMpi91
=NHfl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session cookie max age
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Josh,
On 7/13/2011 2:14 PM, Josh Simmons wrote:
> We tried to set the cookie max age to 3 hours, the exact same time as
> our session timeout.
So, this is a non-session cookie?
> However, I was extremely surprised that the session cookie didn't
> get updated on every request.
Why should it? The information does not change with every request.
> The cookie max age was set when the session was created and that was
> it.
Okay.
> The end result is that our users who stay signed on for longer than
> 3 hours now appear to get logged out.
Is that because your non-session cookie is somehow expected to interact
with the session cookie?
If a user goes 3 hours without any activity, the session expires.
JSESSIONID cookies are, by default, temporary cookies for the user agent
(browser) and do not have an expiration date (that is, they expire when
the browser shuts down). It's up to Tomcat to determine the expiration
time of the actual HTTP session.
> I'm curious about this functionality - why was the decision made to
> not update the session cookie if a max age is set? We can
> effectively get what we want by setting the max age to 24 hours, but
> that seems like the wrong solution.
Can you show your configuration and/or code that is relevant?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4d62wACgkQ9CaO5/Lv0PAkPACfU5RRFYpswrZUk/vfEQqJfukL
HBUAn1/xJVprK2PwBd6iEHobVrwMpi91
=NHfl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org