Discussion:
Multiple JSESSIONID cookies being presented.
Jeffrey Janner
2015-09-04 16:37:31 UTC
Permalink
Hi folks,
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm also seeing this on Windows (version doesn't matter), with Tomcat 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the other APP2. Both contexts start off at a login screen unique to the context and provided by it (not using container auth).
When I connect to ROOT, no problem, but when I connect to APP2, I get 2 JSESSIONID cookies, one with the path "/" and the other with the path "/APP2/".
On the Windows implementations, we are not seeing a problem, at least not one being reported.
On the Linux implementation, the end user will occasionally get immediately kicked out with an invalid session immediately after providing credentials. The access logs show a single jsessionid=xxx being provided on the POST URL. Amazingly, sometimes that goes through and lets the user login, so my theory is that the browser is sometimes picking the wrong path. (Also, theory, the "/" cookie is being generated by a request for "/favicon.ico" just before the request for the login page.)

So my question is: Is there anything I can do from a configuration perspective to get it to NOT send the "/" cookie for APP2?

Deployment details:
Linux is being fronted by an HaProxy server, but the traffic appears to be staying on one host.
Server.xml is essentially the basic one provided with install. Port # and access log information is modified and has RemoteIpValve setup so we can log the end user's IP.
Apps are deployed as war files with static context.xml files in Catalina/localhost. Those files all look like:
<Context>
<Manager pathname="" />
<Resource ...jdbc connection info.... />
</Context>
War files do get exploded. I can't find anything in the web.xml files that have anything to do with cookies.

Any help here would be appreciated.

Jeffrey Janner
Christopher Schultz
2015-09-04 17:45:30 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey,
Post by Jeffrey Janner
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
also seeing this on Windows (version doesn't matter), with Tomcat
7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the other
APP2. Both contexts start off at a login screen unique to the
context and provided by it (not using container auth).
When I connect to ROOT, no problem, but when I connect to APP2, I
get 2 JSESSIONID cookies, one with the path "/" and the other with
the path "/APP2/".
I would expect this behavior: you have one ROOT app (cookie path=/)
and one APP2 app (cookie path=/APP2). Your browser will send both
cookies to /APP2 because / is a prefix of /APP2.
Post by Jeffrey Janner
On the Windows implementations, we are not seeing a problem, at
least not one being reported.
On the Linux implementation, the end user will occasionally get
immediately kicked out with an invalid session immediately after
providing credentials. The access logs show a single
jsessionid=xxx being provided on the POST URL.
The POST to j_security_check?

Are you using request.encodeURL() to build the <form> action URL, or
are you building it manually?

I believe Tomcat prefers the Cookie-based session id to anything
coming-in from the URL, and I do know it will search all JSESSIONID
cookies for any that match a valid session (not just the first one) in
the current application. So logging-in should ... always work.
Post by Jeffrey Janner
Amazingly, sometimes that goes through and lets the user login, so
my theory is that the browser is sometimes picking the wrong path.
(Also, theory, the "/" cookie is being generated by a request for
"/favicon.ico" just before the request for the login page.)
You should make sure that anything that doesn't require authentication
specifically mentions that in web.xml, otherwise you'll get weird
things happening like that.
Post by Jeffrey Janner
So my question is: Is there anything I can do from a
configuration perspective to get it to NOT send the "/" cookie for
APP2?
Not really... other than changing from ROOT to APP1 or whatever.
Overlapping URL spaces for applications leads to tears.
I think there's nothing in here that would change anything.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV6di6AAoJEBzwKT+lPKRY77QQAKzjMEDTVHYzqeFfhS9F9XUO
qrIwlcXlxolclLO2CYaBNoYgcPm1CM8UPMc88s3ysmjLU37dohR8rd1Ukkyp9hdG
0hRV7siKip3t2sj/EDBmslJOKyShlURAqLne14MkQaVvYz/i985MUDrRnlx9zujf
VjR5T0SV+M20ZOXoMN8S1ME09GMJktRajSs5T8rllwvMg+YtdmTo+hWfuerJNrj0
yRBVFkAVs1UOH64RvHud+M3lYleb2UrrE/ZxofDihBcmipKWNEV6W/fu/7uEQVLc
Hysc6CDh90L7xmoV8ndR6QoqNr4gX04mghRaU+PZiB6uPuPgYpJDaJ1wDITOrFnf
BVkXYRh1KICMzSyW1T2K8ZU+NkG4dp0RVI++IzjOuDy+i/EJ9opnNyRols8NkC0w
QLOueV6EbWZFbo9tZxJmaRS7Y7RObcbg/uk5JE9trK4KGcB/MtJQXWhk4Su5ZokS
5+knrgBbWbPcgH5x/1ten/BGkndp28C85FDci0AgsAFCbmim7KuuSL1oRRtLM5kw
WNOeWpJzOQ3FAHV6TqPWLiAclo9/1gTMJZKQtxH+sW5OWYEa/9Ch2ZCArewy5Z+m
KaNMfnXBrXlL9MGYyIQKiFVRUCyn/cyKKAlj9nLVbIBIsHeslCE7zq8zE15EOHVn
7v5mbzif9Ira1ZGLFBjC
=5N0l
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Jeffrey Janner
2015-09-04 19:31:43 UTC
Permalink
-----Original Message-----
Sent: Friday, September 04, 2015 12:46 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Post by Jeffrey Janner
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
also seeing this on Windows (version doesn't matter), with Tomcat
7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the other
APP2. Both contexts start off at a login screen unique to the
context and provided by it (not using container auth).
When I connect to ROOT, no problem, but when I connect to APP2, I
get 2 JSESSIONID cookies, one with the path "/" and the other with
the path "/APP2/".
I would expect this behavior: you have one ROOT app (cookie path=/)
and one APP2 app (cookie path=/APP2). Your browser will send both
cookies to /APP2 because / is a prefix of /APP2.
Post by Jeffrey Janner
On the Windows implementations, we are not seeing a problem, at
least not one being reported.
On the Linux implementation, the end user will occasionally get
immediately kicked out with an invalid session immediately after
providing credentials. The access logs show a single
jsessionid=xxx being provided on the POST URL.
The POST to j_security_check?
No
Are you using request.encodeURL() to build the <form> action URL, or
are you building it manually?
EncodeUrl. And a check of a couple of sites, both linux and windows, shows that the jsessionid is being added to the action by EncodeUrl, regardless of cookie settings. So far, it is always the APP2 sessionID.
I believe Tomcat prefers the Cookie-based session id to anything
coming-in from the URL, and I do know it will search all JSESSIONID
cookies for any that match a valid session (not just the first one) in
the current application. So logging-in should ... always work.
Post by Jeffrey Janner
Amazingly, sometimes that goes through and lets the user login, so
my theory is that the browser is sometimes picking the wrong path.
(Also, theory, the "/" cookie is being generated by a request for
"/favicon.ico" just before the request for the login page.)
You should make sure that anything that doesn't require authentication
specifically mentions that in web.xml, otherwise you'll get weird
things happening like that.
We don't actually use Tomcat container authentication at all.
Post by Jeffrey Janner
So my question is: Is there anything I can do from a
configuration perspective to get it to NOT send the "/" cookie for
APP2?
Not really... other than changing from ROOT to APP1 or whatever.
Overlapping URL spaces for applications leads to tears.
I could do that, though we'd like to keep it so that if no context is specified we still go to APP1, so the user's don't have to change all of their bookmarks. Perhaps with a redirect?
I think there's nothing in here that would change anything.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV6di6AAoJEBzwKT+lPKRY77QQAKzjMEDTVHYzqeFfhS9F9XUO
qrIwlcXlxolclLO2CYaBNoYgcPm1CM8UPMc88s3ysmjLU37dohR8rd1Ukkyp9hdG
0hRV7siKip3t2sj/EDBmslJOKyShlURAqLne14MkQaVvYz/i985MUDrRnlx9zujf
VjR5T0SV+M20ZOXoMN8S1ME09GMJktRajSs5T8rllwvMg+YtdmTo+hWfuerJNrj0
yRBVFkAVs1UOH64RvHud+M3lYleb2UrrE/ZxofDihBcmipKWNEV6W/fu/7uEQVLc
Hysc6CDh90L7xmoV8ndR6QoqNr4gX04mghRaU+PZiB6uPuPgYpJDaJ1wDITOrFnf
BVkXYRh1KICMzSyW1T2K8ZU+NkG4dp0RVI++IzjOuDy+i/EJ9opnNyRols8NkC0w
QLOueV6EbWZFbo9tZxJmaRS7Y7RObcbg/uk5JE9trK4KGcB/MtJQXWhk4Su5ZokS
5+knrgBbWbPcgH5x/1ten/BGkndp28C85FDci0AgsAFCbmim7KuuSL1oRRtLM5kw
WNOeWpJzOQ3FAHV6TqPWLiAclo9/1gTMJZKQtxH+sW5OWYEa/9Ch2ZCArewy5Z+m
KaNMfnXBrXlL9MGYyIQKiFVRUCyn/cyKKAlj9nLVbIBIsHeslCE7zq8zE15EOHVn
7v5mbzif9Ira1ZGLFBjC
=5N0l
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�P�X�] �\X�K�ܙ�B��܈Y][ۘ[��[X[��K[
Christopher Schultz
2015-09-04 19:55:23 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey,
Post by Christopher Schultz
-----Original Message----- From: Christopher Schultz
Subject: Re: Multiple JSESSIONID cookies being presented.
Jeffrey,
Post by Jeffrey Janner
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but
I'm also seeing this on Windows (version doesn't matter),
with Tomcat 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java
7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the
other APP2. Both contexts start off at a login screen unique
to the context and provided by it (not using container
auth).
When I connect to ROOT, no problem, but when I connect to
APP2, I get 2 JSESSIONID cookies, one with the path "/" and
the other with the path "/APP2/".
I would expect this behavior: you have one ROOT app (cookie
path=/) and one APP2 app (cookie path=/APP2). Your browser will
send both cookies to /APP2 because / is a prefix of /APP2.
Post by Jeffrey Janner
On the Windows implementations, we are not seeing a problem,
at least not one being reported.
On the Linux implementation, the end user will occasionally
get immediately kicked out with an invalid session
immediately after providing credentials. The access logs show
a single jsessionid=xxx being provided on the POST URL.
The POST to j_security_check?
No
So... where does the POST go?
Post by Christopher Schultz
Are you using request.encodeURL() to build the <form> action URL,
or are you building it manually?
EncodeUrl. And a check of a couple of sites, both linux and
windows, shows that the jsessionid is being added to the action
by EncodeUrl, regardless of cookie settings. So far, it is always
the APP2 sessionID.
I'm not surprised that the session id is being added to the URL
regardless of cookie settings, because at that point, Tomcat might not
know for sure if the client can support cookies. (I'm sure there are
cases where it's obvious that cookies are in fact supported, but
Tomcat is not detecting it.)

I'm surprised that Tomcat would use the "wrong" session id for
URL-rewriting when presenting the login screen. Are you saying that,
when showing the login page for /APP2, Tomcat will:

a. Place a session identifier in the URL with value X
b. Return a Set-Cookie response header for JSESSIONID with value Y

Where X != Y?
Post by Christopher Schultz
I believe Tomcat prefers the Cookie-based session id to anything
coming-in from the URL, and I do know it will search all
JSESSIONID cookies for any that match a valid session (not just the
first one) in the current application. So logging-in should ...
always work.
Post by Jeffrey Janner
Amazingly, sometimes that goes through and lets the user
login, so my theory is that the browser is sometimes picking
the wrong path. (Also, theory, the "/" cookie is being
generated by a request for "/favicon.ico" just before the
request for the login page.)
You should make sure that anything that doesn't require
authentication specifically mentions that in web.xml, otherwise
you'll get weird things happening like that.
We don't actually use Tomcat container authentication at all.
Okay, that's good information to have. But you do use Tomcat's
session-tracking mechanisms, right?
Post by Christopher Schultz
Post by Jeffrey Janner
So my question is: Is there anything I can do from a
configuration perspective to get it to NOT send the "/"
cookie for APP2?
Not really... other than changing from ROOT to APP1 or whatever.
Overlapping URL spaces for applications leads to tears.
I could do that, though we'd like to keep it so that if no
context is specified we still go to APP1, so the user's don't
have to change all of their bookmarks. Perhaps with a redirect?
That kind of thing is tough to do, but possible. Something like this:

# Ignore requests to /APP1
RewriteCond %{REQUEST_URI} ^/APP1
RewriteRule .* - [L]

# Ignore requests to /APP2
RewriteCond %{REQUEST_URI} ^/APP2
RewriteRule .* - [L]

# Re-write other requests
RewriteRule (.*) /APP1\1 [R,L]

Be very careful with the above: it's completely untested and can put
your clients into a redirect loop if you aren't careful and test all
cases. Also, the [R] flag will do odd things with POST requests, so
either make sure nobody POSTs to one of those URLs or expand the
configuration to properly-handle POSTs.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV6fcrAAoJEBzwKT+lPKRY38QP/26NhBIE6C9QodiEfzrWpH2O
7oPAIvCNjBb2uDD/gZI6QEMR7es0FHfk/8N0/DsS6PJTO8UIOQP4QBrorviUxBQv
Xowwv2rBIfARfYXYUdTAzZemnqYLDAV7eTZVYvnGvXvIpb5C7hInq3TTmMC7KKwh
swB2TauBNiLbHRI2TITq51+1c6CBJAp8/sCAA4i/TBkUPJFxareuyhmKNOJKhikK
bmQcbe30jkz/G9uRaft1byS/JCJot84qiuDBuW/N2y3xMZDOW/nvKUyzhaC+YrC+
SzdakkdTQTJRsVnzEhRSb9nz4fV4XdLyeCDrRhFUrVxUOHcq0p/D38Lqy75SnDRT
ip31AEgdmvWy2/aTVu3LtDsYX9nQzo0s070CctZPesTGtO1u31owF6Gp6stmb1Dy
dh2eaFb1mdWlZo4R/8jd+zgmdC3GQXCrup816BqdXqKHlrtXBqSo1OW/1dS/W2Vp
Ldw89FPsa6tVg47t8bO1We2I/kukjqgqVH49CZqRZsaPOER7ycprWTa0ykTaeOxJ
VpQFjsx3U3+/4RRFp7z9daTMjILrH6eFI9qJWM2LvS1DhpNkiS5+eWX1q1sm5WY9
McbfZXb1L3BcLVx8bp0KhsYLc+Yhkbfp/M84mSVVfrlfLMCRNz/ORQa+SYlYlz0x
wcoVjKS0Ir73it0lLVSK
=pTX5
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Jeffrey Janner
2015-09-04 20:40:15 UTC
Permalink
-----Original Message-----
Sent: Friday, September 04, 2015 2:55 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Post by Christopher Schultz
-----Original Message----- From: Christopher Schultz
Subject: Re: Multiple JSESSIONID cookies being presented.
Jeffrey,
Post by Jeffrey Janner
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but
I'm also seeing this on Windows (version doesn't matter),
with Tomcat 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java
7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the
other APP2. Both contexts start off at a login screen unique
to the context and provided by it (not using container
auth).
When I connect to ROOT, no problem, but when I connect to
APP2, I get 2 JSESSIONID cookies, one with the path "/" and
the other with the path "/APP2/".
I would expect this behavior: you have one ROOT app (cookie
path=/) and one APP2 app (cookie path=/APP2). Your browser will
send both cookies to /APP2 because / is a prefix of /APP2.
Post by Jeffrey Janner
On the Windows implementations, we are not seeing a problem,
at least not one being reported.
On the Linux implementation, the end user will occasionally
get immediately kicked out with an invalid session
immediately after providing credentials. The access logs show
a single jsessionid=xxx being provided on the POST URL.
The POST to j_security_check?
No
So... where does the POST go?
Direct to back-end processing in the app (as far as I know).
Post by Christopher Schultz
Are you using request.encodeURL() to build the <form> action URL,
or are you building it manually?
EncodeUrl. And a check of a couple of sites, both linux and
windows, shows that the jsessionid is being added to the action
by EncodeUrl, regardless of cookie settings. So far, it is always
the APP2 sessionID.
I'm not surprised that the session id is being added to the URL
regardless of cookie settings, because at that point, Tomcat might not
know for sure if the client can support cookies. (I'm sure there are
cases where it's obvious that cookies are in fact supported, but
Tomcat is not detecting it.)
That actually makes sense.
I'm surprised that Tomcat would use the "wrong" session id for
URL-rewriting when presenting the login screen. Are you saying that,
a. Place a session identifier in the URL with value X
b. Return a Set-Cookie response header for JSESSIONID with value Y
Where X != Y?
So far, it looks like it is maintaining an X=Y philosophy.
So that's a non-starter.
Post by Christopher Schultz
I believe Tomcat prefers the Cookie-based session id to anything
coming-in from the URL, and I do know it will search all
JSESSIONID cookies for any that match a valid session (not just the
first one) in the current application. So logging-in should ...
always work.
Post by Jeffrey Janner
Amazingly, sometimes that goes through and lets the user
login, so my theory is that the browser is sometimes picking
the wrong path. (Also, theory, the "/" cookie is being
generated by a request for "/favicon.ico" just before the
request for the login page.)
You should make sure that anything that doesn't require
authentication specifically mentions that in web.xml, otherwise
you'll get weird things happening like that.
We don't actually use Tomcat container authentication at all.
Okay, that's good information to have. But you do use Tomcat's
session-tracking mechanisms, right?
Yes, and the problem only rears its ugly head on a successful login (app expires old cookie, creates a new one).
User never even sees a new page, just an app-generated "session expired" error.
Trying to see things in access logs, but nothing there I can see.
Post by Christopher Schultz
Post by Jeffrey Janner
So my question is: Is there anything I can do from a
configuration perspective to get it to NOT send the "/"
cookie for APP2?
Not really... other than changing from ROOT to APP1 or whatever.
Overlapping URL spaces for applications leads to tears.
I could do that, though we'd like to keep it so that if no
context is specified we still go to APP1, so the user's don't
have to change all of their bookmarks. Perhaps with a redirect?
# Ignore requests to /APP1
RewriteCond %{REQUEST_URI} ^/APP1
RewriteRule .* - [L]
# Ignore requests to /APP2
RewriteCond %{REQUEST_URI} ^/APP2
RewriteRule .* - [L]
# Re-write other requests
RewriteRule (.*) /APP1\1 [R,L]
Be very careful with the above: it's completely untested and can put
your clients into a redirect loop if you aren't careful and test all
cases. Also, the [R] flag will do odd things with POST requests, so
either make sure nobody POSTs to one of those URLs or expand the
configuration to properly-handle POSTs.
Not fronting with HTTPD, so above isn't helpful.
Thinking a new ROOT with just an index.html that redirects to /APP1 or using something like Tuckey for it.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV6fcrAAoJEBzwKT+lPKRY38QP/26NhBIE6C9QodiEfzrWpH2O
7oPAIvCNjBb2uDD/gZI6QEMR7es0FHfk/8N0/DsS6PJTO8UIOQP4QBrorviUxBQv
Xowwv2rBIfARfYXYUdTAzZemnqYLDAV7eTZVYvnGvXvIpb5C7hInq3TTmMC7KKwh
swB2TauBNiLbHRI2TITq51+1c6CBJAp8/sCAA4i/TBkUPJFxareuyhmKNOJKhikK
bmQcbe30jkz/G9uRaft1byS/JCJot84qiuDBuW/N2y3xMZDOW/nvKUyzhaC+YrC+
SzdakkdTQTJRsVnzEhRSb9nz4fV4XdLyeCDrRhFUrVxUOHcq0p/D38Lqy75SnDRT
ip31AEgdmvWy2/aTVu3LtDsYX9nQzo0s070CctZPesTGtO1u31owF6Gp6stmb1Dy
dh2eaFb1mdWlZo4R/8jd+zgmdC3GQXCrup816BqdXqKHlrtXBqSo1OW/1dS/W2Vp
Ldw89FPsa6tVg47t8bO1We2I/kukjqgqVH49CZqRZsaPOER7ycprWTa0ykTaeOxJ
VpQFjsx3U3+/4RRFp7z9daTMjILrH6eFI9qJWM2LvS1DhpNkiS5+eWX1q1sm5WY9
McbfZXb1L3BcLVx8bp0KhsYLc+Yhkbfp/M84mSVVfrlfLMCRNz/ORQa+SYlYlz0x
wcoVjKS0Ir73it0lLVSK
=pTX5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���âW6W'2�V�7V'67&�&TF��6B�6�R��&pФf�"FF�F����6����G2�R�
Christopher Schultz
2015-09-09 18:48:14 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey,
Post by Christopher Schultz
I'm surprised that Tomcat would use the "wrong" session id for
URL-rewriting when presenting the login screen. Are you saying
a. Place a session identifier in the URL with value X b. Return a
Set-Cookie response header for JSESSIONID with value Y
Where X != Y?
So far, it looks like it is maintaining an X=Y philosophy. So
that's a non-starter.
Maybe we aren't communicating well: I'd expect to see X = Y *100% of
the time*. The session id for both the URL *and* the cookie should be
the same, otherwise mass confusion would ensue.
Post by Christopher Schultz
But you do use Tomcat's session-tracking mechanisms, right?
Yes, and the problem only rears its ugly head on a successful
login (app expires old cookie, creates a new one).
Usually, Tomcat won't explicitly expire an old JSESSIONID cookie...
just set another one with a new value. The browser should replace the
old value with the new one.
Post by Christopher Schultz
User never even sees a new page, just an app-generated "session
expired" error. Trying to see things in access logs, but nothing
there I can see.
Hmm.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8H7uAAoJEBzwKT+lPKRYf30QAJ6V2G22zeRhRS7pl3rkhk7w
4/de4gpP+HfS/TYdOrLWr/qn26VPM38xjqPTuOvLTTGNfqgTdKhhrpQwEtHA9iSj
9K3oFmoEN7vXxshKjp2Q5bmjKemez1NVX43bwolq8+fTjVSlGZwTZcSA8+n2rJ05
vV5mBT+O4iqdYT1L1zdUj8XGWBS7hDmL9XCJM+08c4Rxajin37J4Xebi1HBAIM5a
WLijOUNAGHnkfDfpipxBgRcPly/wj//D0TdAZRMLqjVBh3DN6Lxhi59IOIiQgOYc
vu7l+GsimC1QI9/qM88JYlOXzJqpncjdYddyiJXdjvs1b7Rqk2QFGNyzE+njtPYK
icatILkejaN4Ic73mZZtHck50uY7vUagoZCAgsi48vMxsNXraFqrsN6NlKVVI3RN
L11+z7+qftoirWKGgTFmADikm/sknYiaezaVRIYLJohADONeQQ0sd9NpR4LQOU1x
87kWL+6rNfhNrnsWlGpm9PiBY4ZhmfpTcgK5iIJG3/2teCpk6sjye0BuVxkgQUPd
cHiTrhZgEVfkroWLTt55pKvIJmpX6BMA0R43UOk6NwTUrc0oKVqnZvkTMxt95b0m
lhHTRGFloCK3vKpz6ebeKowLz0Pc9rRBn6sQAANZgPd67m8XGjUDZ5lNBuz7XH/D
SfggjrqFB4x52K+EDETR
=LgVZ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Jeffrey Janner
2015-09-08 13:51:13 UTC
Permalink
-----Original Message-----
Sent: Friday, September 04, 2015 12:46 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Post by Jeffrey Janner
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
also seeing this on Windows (version doesn't matter), with Tomcat
7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the other
APP2. Both contexts start off at a login screen unique to the
context and provided by it (not using container auth).
When I connect to ROOT, no problem, but when I connect to APP2, I
get 2 JSESSIONID cookies, one with the path "/" and the other with
the path "/APP2/".
I would expect this behavior: you have one ROOT app (cookie path=/)
and one APP2 app (cookie path=/APP2). Your browser will send both
cookies to /APP2 because / is a prefix of /APP2.
Chris -
I wanted to come back to this case.
Why is the above "expected behavior"?
The client is connecting directly as "https://hostname/APP2" and never going directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on first connection. To me, this seems like a bug.
Only being an admin, I've not fully read the spec, so not sure if the above is really expected behavior.
Now, it's been doing this since at least Tomcat 6, I have one running now, and I've never had a problem with it using direct connections. But now we are front-ending with HaProxy and going to two backend tomcats, and using the JSESSIONID to support sticky-sessions. I'm afraid the multiple cookies is confusing HaProxy. (Yes, I'm going to ask that user community.)
Jeff

Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���âW6W'2�V�7V'67&�&TF��6B�6�R��&pФf�"FF�F����6����G2�R�
Jose María Zaragoza
2015-09-08 14:08:03 UTC
Permalink
Post by Jeffrey Janner
-----Original Message-----
Sent: Friday, September 04, 2015 12:46 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Post by Jeffrey Janner
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
also seeing this on Windows (version doesn't matter), with Tomcat
7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the other
APP2. Both contexts start off at a login screen unique to the
context and provided by it (not using container auth).
When I connect to ROOT, no problem, but when I connect to APP2, I
get 2 JSESSIONID cookies, one with the path "/" and the other with
the path "/APP2/".
I would expect this behavior: you have one ROOT app (cookie path=/)
and one APP2 app (cookie path=/APP2). Your browser will send both
cookies to /APP2 because / is a prefix of /APP2.
Chris -
I wanted to come back to this case.
Why is the above "expected behavior"?
The client is connecting directly as "https://hostname/APP2" and never going directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on first connection. To me, this seems like a bug.
Only being an admin, I've not fully read the spec, so not sure if the above is really expected behavior.
http://www.ietf.org/rfc/rfc2109.txt

The following rules apply to choosing applicable cookie-values from
among all the cookies the user agent has.

Domain Selection
The origin server's fully-qualified host name must domain-match
the Domain attribute of the cookie.

Path Selection
The Path attribute of the cookie must match a prefix of the
request-URI.

Max-Age Selection
Cookies that have expired should have been discarded and thus
are not forwarded to an origin server.

If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific. Ordering with respect to other
attributes (e.g., Domain) is unspecified.
Post by Jeffrey Janner
Now, it's been doing this since at least Tomcat 6, I have one running now, and I've never had a problem with it using direct connections. But now we are front-ending with HaProxy and going to two backend tomcats, and using the JSESSIONID to support sticky-sessions. I'm afraid the multiple cookies is confusing HaProxy. (Yes, I'm going to ask that user community.)
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Jeffrey Janner
2015-09-08 20:57:21 UTC
Permalink
-----Original Message-----
Sent: Tuesday, September 08, 2015 9:08 AM
Subject: Re: Multiple JSESSIONID cookies being presented.
Post by Jeffrey Janner
-----Original Message-----
Sent: Friday, September 04, 2015 12:46 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Post by Jeffrey Janner
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
also seeing this on Windows (version doesn't matter), with Tomcat
7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the other
APP2. Both contexts start off at a login screen unique to the
context and provided by it (not using container auth).
When I connect to ROOT, no problem, but when I connect to APP2, I
get 2 JSESSIONID cookies, one with the path "/" and the other with
the path "/APP2/".
I would expect this behavior: you have one ROOT app (cookie path=/)
and one APP2 app (cookie path=/APP2). Your browser will send both
cookies to /APP2 because / is a prefix of /APP2.
Chris -
I wanted to come back to this case.
Why is the above "expected behavior"?
The client is connecting directly as "https://hostname/APP2" and never
going directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on
first connection. To me, this seems like a bug.
Post by Jeffrey Janner
Only being an admin, I've not fully read the spec, so not sure if the
above is really expected behavior.
http://www.ietf.org/rfc/rfc2109.txt
The following rules apply to choosing applicable cookie-values from
among all the cookies the user agent has.
Domain Selection
The origin server's fully-qualified host name must domain-match
the Domain attribute of the cookie.
Path Selection
The Path attribute of the cookie must match a prefix of the
request-URI.
Max-Age Selection
Cookies that have expired should have been discarded and thus
are not forwarded to an origin server.
If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific. Ordering with respect to other
attributes (e.g., Domain) is unspecified.
Thanks for the clarification of what's supposed to happen on receipt, Jose.
However, I am describing what happens on first contact from the client to the server.
The browser sends https://hostname/APP2, and Tomcat returns:
JSESSIONID=XXXX, path=/ and JSESSIONID=YYYY, path=/APP2/

My contention is that it shouldn't be sending the first one, since it should never route the request to the ROOT app, so it should not be generating a cookie for it.

However, taking what you say above at face value, are you saying that HaProxy should only be forwarding the cookie with path=/APP2/ or should it forward all of them and let Tomcat figure it out.

Jeff
B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�P�X�] �\X�K�ܙ�B��܈Y][ۘ[��[X[��K[
Jose María Zaragoza
2015-09-08 21:11:05 UTC
Permalink
Post by Jeffrey Janner
-----Original Message-----
Sent: Tuesday, September 08, 2015 9:08 AM
Subject: Re: Multiple JSESSIONID cookies being presented.
Post by Jeffrey Janner
-----Original Message-----
Sent: Friday, September 04, 2015 12:46 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Post by Jeffrey Janner
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
also seeing this on Windows (version doesn't matter), with Tomcat
7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the other
APP2. Both contexts start off at a login screen unique to the
context and provided by it (not using container auth).
When I connect to ROOT, no problem, but when I connect to APP2, I
get 2 JSESSIONID cookies, one with the path "/" and the other with
the path "/APP2/".
I would expect this behavior: you have one ROOT app (cookie path=/)
and one APP2 app (cookie path=/APP2). Your browser will send both
cookies to /APP2 because / is a prefix of /APP2.
Chris -
I wanted to come back to this case.
Why is the above "expected behavior"?
The client is connecting directly as "https://hostname/APP2" and never
going directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on
first connection. To me, this seems like a bug.
Post by Jeffrey Janner
Only being an admin, I've not fully read the spec, so not sure if the
above is really expected behavior.
http://www.ietf.org/rfc/rfc2109.txt
The following rules apply to choosing applicable cookie-values from
among all the cookies the user agent has.
Domain Selection
The origin server's fully-qualified host name must domain-match
the Domain attribute of the cookie.
Path Selection
The Path attribute of the cookie must match a prefix of the
request-URI.
Max-Age Selection
Cookies that have expired should have been discarded and thus
are not forwarded to an origin server.
If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific. Ordering with respect to other
attributes (e.g., Domain) is unspecified.
Thanks for the clarification of what's supposed to happen on receipt, Jose.
However, I am describing what happens on first contact from the client to the server.
JSESSIONID=XXXX, path=/ and JSESSIONID=YYYY, path=/APP2/
Sorry, I misunderstood
IMHO, that behaviour is strange .
Indeed, it doesn't make sense for me to return different id ( XXXX ,
YYYY ) if you are accesing to only one context (/APP2)

Are you sure that your webapp deployed in /APP2 is not accesing to
resources ( session-aware resources as JSP, servlet, .. .I mean)
stored in ROOT context ?
Post by Jeffrey Janner
My contention is that it shouldn't be sending the first one, since it should never route the request to the ROOT app, so it should not be generating a cookie for it.
However, taking what you say above at face value, are you saying that HaProxy should only be forwarding the cookie with path=/APP2/ or should it forward all of them and let Tomcat figure it out.
I don't know.
In a later email, I talked you about using another cookie ( SRV_ID )
to balance between backend servers. This feature is implemented by HA
Proxy ( 1.5 at least )
Post by Jeffrey Janner
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Caldarale, Charles R
2015-09-08 21:58:09 UTC
Permalink
Subject: Re: Multiple JSESSIONID cookies being presented.
Post by Jeffrey Janner
Thanks for the clarification of what's supposed to happen on receipt, Jose.
However, I am describing what happens on first contact from the client to the server.
JSESSIONID=XXXX, path=/ and JSESSIONID=YYYY, path=/APP2/
Indeed, it doesn't make sense for me to return different id ( XXXX ,
YYYY ) if you are accesing to only one context (/APP2)
Are you sure that your webapp deployed in /APP2 is not accesing to
resources ( session-aware resources as JSP, servlet, .. .I mean)
stored in ROOT context ?
As I think someone previously mentioned, the client (browser) may well be sending an unsolicited request to the default webapp, such as when trying to retrieve favicon.ico. You might want to run Fiddler or Wireshark on the client to see exactly what's being sent to the server.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Jeffrey Janner
2015-09-09 16:08:33 UTC
Permalink
-----Original Message-----
Sent: Tuesday, September 08, 2015 4:58 PM
Subject: RE: Multiple JSESSIONID cookies being presented.
Subject: Re: Multiple JSESSIONID cookies being presented.
Post by Jeffrey Janner
Thanks for the clarification of what's supposed to happen on
receipt, Jose.
Post by Jeffrey Janner
However, I am describing what happens on first contact from the
client to the server.
Post by Jeffrey Janner
JSESSIONID=XXXX, path=/ and JSESSIONID=YYYY, path=/APP2/
Indeed, it doesn't make sense for me to return different id ( XXXX ,
YYYY ) if you are accesing to only one context (/APP2)
Are you sure that your webapp deployed in /APP2 is not accesing to
resources ( session-aware resources as JSP, servlet, .. .I mean)
stored in ROOT context ?
As I think someone previously mentioned, the client (browser) may well
be sending an unsolicited request to the default webapp, such as when
trying to retrieve favicon.ico. You might want to run Fiddler or
Wireshark on the client to see exactly what's being sent to the server.
And there's no way to keep a browser from asking for the favicon.ico file from the root.
We don't have one, so I would expect a 404 is sent, which looking at the access log file is what happens.
However, is this the issue? I tested this doing a manual https://hostname/favicon.ico and see that we also return our root app's error page. We also seem to be doing that for the auto-generated request, judging by the bytes returned value, even though it won't get displayed.
And I bet that the error page is setting the session cookie for some reason.
Does that sound reasonable?
Is my solution just providing a favicon.ico file?
Jeff

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Jose María Zaragoza
2015-09-09 17:08:43 UTC
Permalink
Post by Jeffrey Janner
-----Original Message-----
Sent: Tuesday, September 08, 2015 4:58 PM
Subject: RE: Multiple JSESSIONID cookies being presented.
Subject: Re: Multiple JSESSIONID cookies being presented.
Post by Jeffrey Janner
Thanks for the clarification of what's supposed to happen on
receipt, Jose.
Post by Jeffrey Janner
However, I am describing what happens on first contact from the
client to the server.
Post by Jeffrey Janner
JSESSIONID=XXXX, path=/ and JSESSIONID=YYYY, path=/APP2/
Indeed, it doesn't make sense for me to return different id ( XXXX ,
YYYY ) if you are accesing to only one context (/APP2)
Are you sure that your webapp deployed in /APP2 is not accesing to
resources ( session-aware resources as JSP, servlet, .. .I mean)
stored in ROOT context ?
As I think someone previously mentioned, the client (browser) may well
be sending an unsolicited request to the default webapp, such as when
trying to retrieve favicon.ico. You might want to run Fiddler or
Wireshark on the client to see exactly what's being sent to the server.
And there's no way to keep a browser from asking for the favicon.ico file from the root.
We don't have one, so I would expect a 404 is sent, which looking at the access log file is what happens.
However, is this the issue? I tested this doing a manual https://hostname/favicon.ico and see that we also return our root app's error page. We also seem to be doing that for the auto-generated request, judging by the bytes returned value, even though it won't get displayed.
And I bet that the error page is setting the session cookie for some reason.
Does that sound reasonable?
If you write https://hostname/favicon.ico into your browser's url address bar
does it return a JSESSIONID ?
If it does , why do your error html page is creating a HTTP session ?
Is it a error.jsp ?
Post by Jeffrey Janner
Is my solution just providing a favicon.ico file?
Jeff
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Christopher Schultz
2015-09-09 18:49:58 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey,
Post by Jeffrey Janner
-----Original Message----- From: Caldarale, Charles R
Subject: RE: Multiple JSESSIONID cookies being presented.
Subject: Re: Multiple JSESSIONID cookies being presented.
Post by Jeffrey Janner
Thanks for the clarification of what's supposed to happen on
receipt, Jose.
Post by Jeffrey Janner
However, I am describing what happens on first contact from
the
client to the server.
Post by Jeffrey Janner
JSESSIONID=XXXX, path=/ and JSESSIONID=YYYY,
path=/APP2/
Indeed, it doesn't make sense for me to return different id (
XXXX , YYYY ) if you are accesing to only one context (/APP2)
Are you sure that your webapp deployed in /APP2 is not accesing
to resources ( session-aware resources as JSP, servlet, .. .I
mean) stored in ROOT context ?
As I think someone previously mentioned, the client (browser) may
well be sending an unsolicited request to the default webapp,
such as when trying to retrieve favicon.ico. You might want to
run Fiddler or Wireshark on the client to see exactly what's
being sent to the server.
And there's no way to keep a browser from asking for the
favicon.ico file from the root. We don't have one, so I would
expect a 404 is sent, which looking at the access log file is what
happens. However, is this the issue? I tested this doing a manual
https://hostname/favicon.ico and see that we also return our root
app's error page. We also seem to be doing that for the
auto-generated request, judging by the bytes returned value, even
though it won't get displayed. And I bet that the error page is
setting the session cookie for some reason. Does that sound
reasonable? Is my solution just providing a favicon.ico file?
Can you make sure that all cookies have been cleared from the test
client and then explain exactly when Tomcat sends the Set-Cookie headers
?

When we had this problem, it was usually because the client had old
funky session ids in its cookie jar and the solution was to blow them
all away and start-over fresh. (Then fix our software so it wouldn't
happen anymore.)

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8H9WAAoJEBzwKT+lPKRYUrUP/jFofb1kyXtipLisOXrDRKRi
dXgapMR+XsBMUNBqQOCbwM1YRn2IV9+pF2oJaLtN/R36rweoYMywvbqc6LWG+MuL
oOu8Qe7t5RRXVbOdvP5hYPTNiVDNGPYSmPHg5gbGsPNfhUWqMNutWbQBxZwjX+kH
Q0P71bgk2Nf4Ch0wqjQImCsO+oQH2BeHUOCC7FLYsRa8r8nS8Ml0MXmvQl57yZzB
cUm/V4Z1ygh8QxvB2ZmIber2KFVx4gJyZh6usTnpkb0lm7x1H0PUylpklyYSTJKv
thR3DSgVjLe582I8/2/rIjpGhqqP/TUAv9INh7WprzLGTb4wQQRKkPYAwy/9vxhI
4+PDs6qTalS9iti8GdA5MIg6CuK55Gu26rvlC+FNSsYQMMMzedySTri1tJQgCkJd
JQL97eoouNFd3K06EuCyUWIoOfGqCNNoYpDYaxN/IeBwbefSR8mUctWsWKDdX6MJ
p7/I3saRu3na8oLR4nnZz8a/I/oIQWwvJebHMN3UFuSgBLxIwgurE6LHZ8tSP2YP
D/QYKSnY+KoGb7tPR4O0FTxr7EULUFtVgWPCy6WePi1jkVxqmKPD3rIU+TtPzwLb
QDiI4W4O3lL97F1iZNcjNGnbDgpOcJdhJjORFQl/KEX8r6D9fN0h0LjgSuuEJnr7
JrNmcEq8wsZxM1VgxtRn
=ZL2V
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Jeffrey Janner
2015-09-10 16:26:07 UTC
Permalink
-----Original Message-----
Sent: Wednesday, September 09, 2015 1:50 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Post by Jeffrey Janner
-----Original Message----- From: Caldarale, Charles R
Subject: RE: Multiple JSESSIONID cookies being presented.
Subject: Re: Multiple JSESSIONID cookies being presented.
Post by Jeffrey Janner
Thanks for the clarification of what's supposed to happen on
receipt, Jose.
Post by Jeffrey Janner
However, I am describing what happens on first contact from the
client to the server.
Post by Jeffrey Janner
JSESSIONID=XXXX, path=/ and JSESSIONID=YYYY,
path=/APP2/
Indeed, it doesn't make sense for me to return different id (
XXXX , YYYY ) if you are accesing to only one context (/APP2)
Are you sure that your webapp deployed in /APP2 is not accesing
to resources ( session-aware resources as JSP, servlet, .. .I
mean) stored in ROOT context ?
As I think someone previously mentioned, the client (browser) may
well be sending an unsolicited request to the default webapp,
such as when trying to retrieve favicon.ico. You might want to
run Fiddler or Wireshark on the client to see exactly what's
being sent to the server.
And there's no way to keep a browser from asking for the
favicon.ico file from the root. We don't have one, so I would
expect a 404 is sent, which looking at the access log file is what
happens. However, is this the issue? I tested this doing a manual
https://hostname/favicon.ico and see that we also return our root
app's error page. We also seem to be doing that for the
auto-generated request, judging by the bytes returned value, even
though it won't get displayed. And I bet that the error page is
setting the session cookie for some reason. Does that sound
reasonable? Is my solution just providing a favicon.ico file?
Can you make sure that all cookies have been cleared from the test
client and then explain exactly when Tomcat sends the Set-Cookie headers
?
When we had this problem, it was usually because the client had old
funky session ids in its cookie jar and the solution was to blow them
all away and start-over fresh. (Then fix our software so it wouldn't
happen anymore.)
- -chris
Thanks for all the help guys. I think I've sussed out what is going on here. Now just have to get the Dev guys to address it.
After spending a good bit of time clearing and watching cookies and access logs, both with and without a favicon.ico file, I found that the doubling was happening only if the file was missing. I checked the error.jsp file and it does have session=true set, and if the icon file is missing, the error.jsp is definitely being sent.
So it looks like the possible solutions are:
1) provide a favicon.ico file.
2) remove the session=true setting from the error page.
3) somehow not send the error.jsp when a sub-link (image, script, etc.) results in a 404.
4) Have the login page of APP2 provide it's own icon <link> directive (it doesn't currently have one.)

Any other options?
Jeff

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-m
Caldarale, Charles R
2015-09-10 17:00:40 UTC
Permalink
Subject: RE: Multiple JSESSIONID cookies being presented.
I checked the error.jsp file and it does have session=true set, and if the icon file
is missing, the error.jsp is definitely being sent.
1) provide a favicon.ico file.
2) remove the session=true setting from the error page.
3) somehow not send the error.jsp when a sub-link (image, script, etc.) results in a 404.
4) Have the login page of APP2 provide it's own icon <link> directive (it doesn't currently
have one.)
Why would you ever want your error.jsp to create a session? Sounds like an easy DoS attack to me.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Jeffrey Janner
2015-09-11 14:01:31 UTC
Permalink
-----Original Message-----
Sent: Thursday, September 10, 2015 12:01 PM
Subject: RE: Multiple JSESSIONID cookies being presented.
Subject: RE: Multiple JSESSIONID cookies being presented.
I checked the error.jsp file and it does have session=true set, and if
the icon file
is missing, the error.jsp is definitely being sent.
1) provide a favicon.ico file.
2) remove the session=true setting from the error page.
3) somehow not send the error.jsp when a sub-link (image, script,
etc.) results in a 404.
4) Have the login page of APP2 provide it's own icon <link> directive
(it doesn't currently
have one.)
Why would you ever want your error.jsp to create a session? Sounds like
an easy DoS attack to me.
- Chuck
Programmers. What more do I need to say....


---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Christopher Schultz
2015-09-10 19:23:41 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey,
Post by Jeffrey Janner
Thanks for all the help guys. I think I've sussed out what is
going on here. Now just have to get the Dev guys to address it.
After spending a good bit of time clearing and watching cookies
and access logs, both with and without a favicon.ico file, I found
that the doubling was happening only if the file was missing. I
checked the error.jsp file and it does have session=true set, and
if the icon file is missing, the error.jsp is definitely being
sent.
So it looks like the possible solutions are: 1) provide a
favicon.ico file.
This fixes the symptom, not the problem. You'll get the same problem
with clients who request /apple-touch-icon.png, /robots.txt, or just
about any other file that ends up resulting in a 404. This could be
something from within the application itself, and will (apparently)
cause mass confusion.
Post by Jeffrey Janner
2) remove the session=true setting from the error page.
This is the right answer. Do you really need the session in error.jsp?
Post by Jeffrey Janner
3) somehow not send the error.jsp when a sub-link (image, script, etc.) results in a 404.
4) Have the login page of APP2 provide it's own icon <link>
directive (it doesn't currently have one.)
Any other options?
If you absolutely need access to the session in your error.jsp file,
you can do this:

<?jsp session="false" ?>
<%
HttpSession session = request.getSession(false);

...
%>

This will prevent sessions from being created when there isn't already
a session. You'll have to check the code for error.jsp to make sure
that no code uses the session before checking it for null -- because
session="true" guarantees that the "session" reference will be non-null.

That will allow you to use session information in error.jsp if a
session already exists, but not create a superfluous session when one
does not (yet) exist.

Back to Tomcat's session management: Tomcat *can* handle this
situation properly: it will try all JSESSIONID cookies it gets to find
a valid one in the current web application. So, multiple JSESSIONID
cookies won't confuse Tomcat. Some other component must be
mis-understanding the session identifier in some way.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8di9AAoJEBzwKT+lPKRY9FUP/0m2SNIG3nW9dsIRCr1q/SWG
5O/s5VrDs7Rvk1hWfbGTlhfuL0zkeCaL/GQE4wa3KQo4qHPhtzYlIgZstEeaAQqk
kLwU4JHzJcTfKMKog6/O0kFwysYzl4y/EX+UoBcY3h3N5xkQ0RGNOYEF7fSr+6NA
Uuxo6WVxQoP3Ce/64EZ1P+uxglLJF+pML6OViEHEK4qgL3SY1UY0tOFpcBa43Gqt
Y/Z7I1SvQhRt2VGQzyatHRypAMxynJfHjvV/gyF3k1/XFEeWDDpET4guaazD1uqW
fE5Lgt3Lxr1WyeEXxeJz4jOlLBty0bm9m16YFdxCsNjVy7v7Uy7M1Hd0iIfoktCV
Vp8nzuj+qxVMpzua2N/J7e9slYnIZOePOFFrTQbWx1S10QCvgRuprN3lyZEU29oP
PywXQU/F9u/xFPk6Z5+xdMrSEvL+ykuwoyV8Ef2CObZ0Ibsjx9WoBAz/hRLpeeji
TngPwFvDrU7jMR36SQ+vCR8PQSjQo5P2P+KZE735uIgG/iz3F6gQ+8R9E0p1iutL
iLoF2alPkSaoWnBTrlDhV+EvKtjKl2FWuRrs5sHGWG6FowS+lKnaAfhkq3ArGLdS
j4JFculpE80Ys9saoetvTlQ35dTi1KdmL+gzixI/EjUVkS2azsW6kYxkwliig4gN
UVa6wuFsD/I9JcMCKeIp
=1OQG
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Jeffrey Janner
2015-09-11 14:09:17 UTC
Permalink
-----Original Message-----
Sent: Thursday, September 10, 2015 2:24 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Post by Jeffrey Janner
Thanks for all the help guys. I think I've sussed out what is
going on here. Now just have to get the Dev guys to address it.
After spending a good bit of time clearing and watching cookies
and access logs, both with and without a favicon.ico file, I found
that the doubling was happening only if the file was missing. I
checked the error.jsp file and it does have session=true set, and
if the icon file is missing, the error.jsp is definitely being
sent.
So it looks like the possible solutions are: 1) provide a
favicon.ico file.
This fixes the symptom, not the problem. You'll get the same problem
with clients who request /apple-touch-icon.png, /robots.txt, or just
about any other file that ends up resulting in a 404. This could be
something from within the application itself, and will (apparently)
cause mass confusion.
Post by Jeffrey Janner
2) remove the session=true setting from the error page.
This is the right answer. Do you really need the session in error.jsp?
Post by Jeffrey Janner
3) somehow not send the error.jsp when a sub-link (image, script,
etc.) results in a 404.
4) Have the login page of APP2 provide it's own icon <link>
directive (it doesn't currently have one.)
Any other options?
If you absolutely need access to the session in your error.jsp file,
<?jsp session="false" ?>
<%
HttpSession session = request.getSession(false);
...
%>
This will prevent sessions from being created when there isn't already
a session. You'll have to check the code for error.jsp to make sure
that no code uses the session before checking it for null -- because
session="true" guarantees that the "session" reference will be non-null.
That will allow you to use session information in error.jsp if a
session already exists, but not create a superfluous session when one
does not (yet) exist.
Thanks for the above Chris. I passed the information on to someone who can get it implemented.
Back to Tomcat's session management: Tomcat *can* handle this
situation properly: it will try all JSESSIONID cookies it gets to find
a valid one in the current web application. So, multiple JSESSIONID
cookies won't confuse Tomcat. Some other component must be
mis-understanding the session identifier in some way.
- -chris
Yes, I don't think it's bothering Tomcat at all. We've never experienced a problem with direct-to-tomcat configurations, and we've had this setup for years.
We recently implemented an HaProxy front-end using stick-tables and think it's potentially confusing HaProxy. But I can't swear to that, because I did find a problem with how jvmRoute was being applied, resulting in both servers providing the same value, so that could have been the underlying problem all along.
However, the session on error is a basics issue that needs to be resolved.
Thanks again. I think we are done here.
Jeff
Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���âW6W'2�V�7V'67&�&TF��6B�6�R��&pФf�"FF�F����6����G2�R�
Christopher Schultz
2015-09-11 20:55:56 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeff,
Post by Jeffrey Janner
-----Original Message----- From: Christopher Schultz
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Jeffrey,
Post by Jeffrey Janner
Thanks for all the help guys. I think I've sussed out what is
going on here. Now just have to get the Dev guys to address
it.
After spending a good bit of time clearing and watching
cookies and access logs, both with and without a favicon.ico
file, I found that the doubling was happening only if the file
was missing. I checked the error.jsp file and it does have
session=true set, and if the icon file is missing, the
error.jsp is definitely being sent.
So it looks like the possible solutions are: 1) provide a
favicon.ico file.
This fixes the symptom, not the problem. You'll get the same
problem with clients who request /apple-touch-icon.png,
/robots.txt, or just about any other file that ends up resulting
in a 404. This could be something from within the application
itself, and will (apparently) cause mass confusion.
Post by Jeffrey Janner
2) remove the session=true setting from the error page.
This is the right answer. Do you really need the session in
error.jsp?
Post by Jeffrey Janner
3) somehow not send the error.jsp when a sub-link (image,
script, etc.) results in a 404.
4) Have the login page of APP2 provide it's own icon <link>
directive (it doesn't currently have one.)
Any other options?
If you absolutely need access to the session in your error.jsp
<?jsp session="false" ?> <% HttpSession session =
request.getSession(false);
... %>
This will prevent sessions from being created when there isn't
already a session. You'll have to check the code for error.jsp to
make sure that no code uses the session before checking it for
null -- because session="true" guarantees that the "session"
reference will be non-null.
That will allow you to use session information in error.jsp if a
session already exists, but not create a superfluous session when
one does not (yet) exist.
Thanks for the above Chris. I passed the information on to someone
who can get it implemented.
Back to Tomcat's session management: Tomcat *can* handle this
situation properly: it will try all JSESSIONID cookies it gets to
find a valid one in the current web application. So, multiple
JSESSIONID cookies won't confuse Tomcat. Some other component
must be mis-understanding the session identifier in some way.
- -chris
Yes, I don't think it's bothering Tomcat at all. We've never
experienced a problem with direct-to-tomcat configurations, and
we've had this setup for years. We recently implemented an HaProxy
front-end using stick-tables and think it's potentially confusing
HaProxy. But I can't swear to that, because I did find a problem
with how jvmRoute was being applied, resulting in both servers
providing the same value, so that could have been the underlying
problem all along. However, the session on error is a basics issue
that needs to be resolved. Thanks again. I think we are done
here.
I think I missed that part about switching to HAProxy. If you are
using sticky sessions, HAProxy needs to know that session X was
replaced by session Y. That ought to happen because Tomcat will be
sending Set-Cookie response headers, and HAProxy ought to pick-up on
it, but it's possible something is getting confused during the scuffle.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8z/cAAoJEBzwKT+lPKRYLnkP/icNKczwo6lNH+mCd4mMnTUn
9Lsgz+sRDxjE4d8+ccKlv1cYi+ava0zEAQWgKgeWcxaBGO9NvUyTiXy6CIQKMBNW
dNYQBreU2aVDlFAuLHPzCGSjSRpt9RFC15tCrAqCFKXcQF8S3pkYtzEWgwXVB1mH
5GRpkqyMj+4HDPDUVQXxu5NBUPuu7p2JZroMtXeo0Na1P6AXpmer0/KOqR0EYDwD
oGYMKtRWcZcXeYpUJNi1PlWYLl753N1tJL5j1rwXUJKOG25mekhf3tX9V4EjALOp
LvA1/GSD5OQMEBfzBXEIjT5dmRJMwi1mkPGwzFtS9FN0dVCdhjofCIdnPLTCGXy8
R9dHIcql3EEcq2zulW4Ai6e7rm57CkwEPzuwT1p+pjVkH0fj7zaZJhjcZaKzFoRc
fkwA/9Q3P6l/f6xkjeI07kXtY8MqdHLWK/nIISs1F4vbJfKQ5Ki0Aw1jJwgzn/1O
ITFWRk5WW5IJsXkoItFUBMbkqsNNi319rg64XJFS9Dt8oKRaw+ENwKPOZVSCZ05n
l9nxtj8kiqGNaigG7WcAfQSsx8JUbRvpt44yTI6zl7zLav+Dcig5DKeHpztfvxDb
aumO17zH2KwUh2zfdl7zFr6mc7AYYkaQb/1lpM4ehvsvXIStj45J00tzvkKLrYwp
M6N24e0Oia9aBzmLoiVc
=egHr
-----END PGP SIGNATURE-----

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

Jose María Zaragoza
2015-09-08 14:21:40 UTC
Permalink
Post by Jeffrey Janner
-----Original Message-----
Sent: Friday, September 04, 2015 12:46 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Now, it's been doing this since at least Tomcat 6, I have one running now, and I've never had a problem with it using direct connections. But now we are front-ending with HaProxy and going to two backend tomcats, and using the JSESSIONID to support sticky-sessions. I'm afraid the multiple cookies is confusing HaProxy. (Yes, I'm going to ask that user community.)
Jeff
You could use another cookie to implement stickyness

"You can add a cookie SOME-COOKIE-NAME prefix directive into the
backend. Then simply add the cookie directive within each server. Then
HAProxy will append a cookie (or add onto an existing one) a
identifier for each server. This cookie will be sent back in
subsequent requests from the client, letting HAProxy know which server
to send the request to. This looks like the following:"

backend nodes
# Other options above omitted for brevity
cookie SRV_ID prefix
server web01 127.0.0.1:9000 cookie check
server web02 127.0.0.1:9001 cookie check
server web03 127.0.0.1:9002 cookie check


https://serversforhackers.com/load-balancing-with-haproxy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
Jeffrey Janner
2015-09-08 21:09:56 UTC
Permalink
-----Original Message-----
Sent: Tuesday, September 08, 2015 9:22 AM
Subject: Re: Multiple JSESSIONID cookies being presented.
Post by Jeffrey Janner
-----Original Message-----
Sent: Friday, September 04, 2015 12:46 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Now, it's been doing this since at least Tomcat 6, I have one running
now, and I've never had a problem with it using direct connections. But
now we are front-ending with HaProxy and going to two backend tomcats,
and using the JSESSIONID to support sticky-sessions. I'm afraid the
multiple cookies is confusing HaProxy. (Yes, I'm going to ask that user
community.)
Post by Jeffrey Janner
Jeff
You could use another cookie to implement stickyness
"You can add a cookie SOME-COOKIE-NAME prefix directive into the
backend. Then simply add the cookie directive within each server. Then
HAProxy will append a cookie (or add onto an existing one) a
identifier for each server. This cookie will be sent back in
subsequent requests from the client, letting HAProxy know which server
to send the request to. This looks like the following:"
backend nodes
# Other options above omitted for brevity
cookie SRV_ID prefix
server web01 127.0.0.1:9000 cookie check
server web02 127.0.0.1:9001 cookie check
server web03 127.0.0.1:9002 cookie check
https://serversforhackers.com/load-balancing-with-haproxy
Thanks Jose. We considered that, as well as having HaProxy just generate its own sticky-session cookie, but it seemed like a better idea to just let Tomcat handle it and use stick-tables. We are moving towards a fully-clustered tomcat, so already having the config in place such that we only have to turn off the stick-tables and we'd be set to go. I'll eventually be supporting a fairly large number of backends and don't want to make the configuration of new ones very complicated. Making them simple and pushing the complication down to the tomcat level just seemed to make more sense.
In fact, I've parameterized the jvmRoute setting in the Tomcat server.xml and use the setenv.sh script to calculate the value based on the server the Tomcat is running on.
If only there were some way to have HaProxy read an already existing suffix in the cookie string, like httpd, my life would be perfect.
Jeff

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-m
Igor Cicimov
2015-09-09 03:09:21 UTC
Permalink
Post by Jeffrey Janner
-----Original Message-----
Sent: Tuesday, September 08, 2015 9:22 AM
Subject: Re: Multiple JSESSIONID cookies being presented.
Post by Jeffrey Janner
-----Original Message-----
Sent: Friday, September 04, 2015 12:46 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Now, it's been doing this since at least Tomcat 6, I have one running
now, and I've never had a problem with it using direct connections. But
now we are front-ending with HaProxy and going to two backend tomcats,
and using the JSESSIONID to support sticky-sessions. I'm afraid the
multiple cookies is confusing HaProxy. (Yes, I'm going to ask that user
community.)
Post by Jeffrey Janner
Jeff
You could use another cookie to implement stickyness
"You can add a cookie SOME-COOKIE-NAME prefix directive into the
backend. Then simply add the cookie directive within each server. Then
HAProxy will append a cookie (or add onto an existing one) a
identifier for each server. This cookie will be sent back in
subsequent requests from the client, letting HAProxy know which server
to send the request to. This looks like the following:"
backend nodes
# Other options above omitted for brevity
cookie SRV_ID prefix
server web01 127.0.0.1:9000 cookie check
server web02 127.0.0.1:9001 cookie check
server web03 127.0.0.1:9002 cookie check
https://serversforhackers.com/load-balancing-with-haproxy
Thanks Jose. We considered that, as well as having HaProxy just generate
its own sticky-session cookie, but it seemed like a better idea to just let
Tomcat handle it and use stick-tables. We are moving towards a
fully-clustered tomcat, so already having the config in place such that we
only have to turn off the stick-tables and we'd be set to go. I'll
eventually be supporting a fairly large number of backends and don't want
to make the configuration of new ones very complicated. Making them simple
and pushing the complication down to the tomcat level just seemed to make
more sense.

If using more than one haproxy inserting its own cookie is much better
solution since you don't have to sync the stick tables between the lb's.
Post by Jeffrey Janner
In fact, I've parameterized the jvmRoute setting in the Tomcat server.xml
and use the setenv.sh script to calculate the value based on the server the
Tomcat is running on.
Post by Jeffrey Janner
If only there were some way to have HaProxy read an already existing
suffix in the cookie string, like httpd, my life would be perfect.
Post by Jeffrey Janner
Jeff
---------------------------------------------------------------------
Jeffrey Janner
2015-09-09 14:28:01 UTC
Permalink
-----Original Message-----
Sent: Tuesday, September 08, 2015 10:09 PM
Subject: RE: Multiple JSESSIONID cookies being presented.
Post by Jeffrey Janner
-----Original Message-----
Sent: Tuesday, September 08, 2015 9:22 AM
Subject: Re: Multiple JSESSIONID cookies being presented.
2015-09-08 15:51 GMT+02:00 Jeffrey Janner
Post by Jeffrey Janner
-----Original Message-----
Sent: Friday, September 04, 2015 12:46 PM
Subject: Re: Multiple JSESSIONID cookies being presented.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
Now, it's been doing this since at least Tomcat 6, I have one
running
Post by Jeffrey Janner
now, and I've never had a problem with it using direct connections.
But
Post by Jeffrey Janner
now we are front-ending with HaProxy and going to two backend
tomcats,
Post by Jeffrey Janner
and using the JSESSIONID to support sticky-sessions. I'm afraid the
multiple cookies is confusing HaProxy. (Yes, I'm going to ask that
user
Post by Jeffrey Janner
community.)
Post by Jeffrey Janner
Jeff
You could use another cookie to implement stickyness
"You can add a cookie SOME-COOKIE-NAME prefix directive into the
backend. Then simply add the cookie directive within each server.
Then
Post by Jeffrey Janner
HAProxy will append a cookie (or add onto an existing one) a
identifier for each server. This cookie will be sent back in
subsequent requests from the client, letting HAProxy know which
server
Post by Jeffrey Janner
to send the request to. This looks like the following:"
backend nodes
# Other options above omitted for brevity
cookie SRV_ID prefix
server web01 127.0.0.1:9000 cookie check
server web02 127.0.0.1:9001 cookie check
server web03 127.0.0.1:9002 cookie check
https://serversforhackers.com/load-balancing-with-haproxy
Thanks Jose. We considered that, as well as having HaProxy just
generate
its own sticky-session cookie, but it seemed like a better idea to just let
Tomcat handle it and use stick-tables. We are moving towards a
fully-clustered tomcat, so already having the config in place such that we
only have to turn off the stick-tables and we'd be set to go. I'll
eventually be supporting a fairly large number of backends and don't want
to make the configuration of new ones very complicated. Making them simple
and pushing the complication down to the tomcat level just seemed to make
more sense.
If using more than one haproxy inserting its own cookie is much better
solution since you don't have to sync the stick tables between the lb's.
Post by Jeffrey Janner
In fact, I've parameterized the jvmRoute setting in the Tomcat
server.xml
and use the setenv.sh script to calculate the value based on the server the
Tomcat is running on.
Post by Jeffrey Janner
If only there were some way to have HaProxy read an already existing
suffix in the cookie string, like httpd, my life would be perfect.
Post by Jeffrey Janner
Jeff
Thanks Igor. We may have to look into that in the future. We are running multiple HaProxy servers relying on Round robin DNS, so we need to have some method of insuring a consistent cookie between the two HaProxy servers.
Thanks again.
Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���âW6W'2�V�7V'67&�&TF��6B�6�R��&pФf�"FF�F����6����G2�R�
Loading...