You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Martin <ma...@gleichklang.de> on 2013/11/08 15:59:51 UTC
Session init problem since moving to new server/tomcat
Recently we moved our application from an old ubuntu to a newer centos
box. We upgraded our JAVA version, tomcat (from v5 to latest v6) and
basically all server components. Local tests of our application showed
no problems with these newer versions, in fact it has been developed
with these since quite some time.
But now we seem to have a problem with our session management/creation,
however only on the new live server, not locally.
Whenever a user visits a page (the login page) for the very first time
(no JSESSIONID-Cookie), the first login form submit does not work. Our
live application obviously encounters some kind of unexpected stuff. The
followup form submit works as expected. The JSESSIONID is created on the
first page load btw.
The person who wrote this part of our application has gone AWOL and
locally we cannot reproduce this.
Do you guys have any idea what could be responsible for this? I
obviously copied all the tomcat settings from the older version and I
cannot find anything worthy in the logs.
Thanks,
Martin
http://www.gleichklang-mail.de: Der Email-Zugang für ökologisch und sozial denkende Menschen!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session init problem since moving to new server/tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Martin,
On 11/8/13, 11:40 AM, Martin wrote:
> Thank you Christopher for your in depth annotations. We just
> downgraded from v6.0.34 to .20 and the problem has vanished. We
> obviously have some changes to do before we can upgrade to v7 as
> far as the session handling is concerned. Your post will help us
> along the way. Thanks again.
I really suspect the session id switching is the problem. Check the
changelog between .20 and .34 for things that smell like they might be
related to your issue.
You should really re-upgrade back to 6.0.latest as soon as you can:
there are good performance and important security updates included in
those later versions.
- -chris
> Am 2013-11-08 16:22, schrieb Christopher Schultz: Martin,
>
> On 11/8/13, 9:59 AM, Martin wrote:
>>>> Recently we moved our application from an old ubuntu to a
>>>> newer centos box. We upgraded our JAVA version, tomcat (from
>>>> v5 to latest v6) and basically all server components.
>
> I would highly recommend that you upgrade directly to 7.0.x...
> moving from Tomcat 6 to Tomcat 7 is much easier than the transition
> from 5.0 to 6.0. Make the investment, now. Tomcat 8 is just around
> the corner which means that Tomcat 6's days are numbered (though it
> may still have 1000 days left in its lifetime).
>
>>>> Local tests of our application showed no problems with these
>>>> newer versions, in fact it has been developed with these
>>>> since quite some time.
>>>>
>>>> But now we seem to have a problem with our session
>>>> management/creation, however only on the new live server,
>>>> not locally.
>>>>
>>>> Whenever a user visits a page (the login page) for the very
>>>> first time (no JSESSIONID-Cookie), the first login form
>>>> submit does not work. Our live application obviously
>>>> encounters some kind of unexpected stuff. The followup form
>>>> submit works as expected. The JSESSIONID is created on the
>>>> first page load btw.
>
> What does your login <form> look like? Often, users forget to
> encode the session id in the URL for the form like this:
>
> <form action="j_security_check">
>
> It would be better to do this:
>
> <form action="<%= response.encoreURL(request.getContextPath() +
> "/j_security_check")) %>" />
>
> That way, Tomcat will get the session identifier whether cookies
> are in use or not.
>
>>>> The person who wrote this part of our application has gone
>>>> AWOL and locally we cannot reproduce this.
>>>>
>>>> Do you guys have any idea what could be responsible for this?
>>>> I obviously copied all the tomcat settings from the older
>>>> version and I cannot find anything worthy in the logs.
>
> Some things have changed from Tomcat 5 to Tomcat 6 and later,
> especially with session-handling during login. For example, Tomcat
> now switches session-ids after a successful login in order to
> protect against session-fixation attacks. Also, Tomcat now requires
> (though I'm not sure if this is different from the Tomcat 5 days) a
> session to be in place in order to show the login screen because it
> needs to store the original request somewhere for a
> post-authentication redirect.
>
> Are you using the "standard" spec-defined login process:
>
> 1. User requests a protected page 2. Container challenges user for
> credentials 3. User provides valid credentials 4. Container sends
> the user to the originally-requested resource
>
> ?
>
> Or, are you using what I call a drive-by login where you just have
> the login page showing in index.jsp or whatever with a login
> button? This last one won't work the way you expect it to work,
> because the spec (stupidly, IMO) didn't include a standard way for
> containers to handle "unsolicited" logins.
>
> These days (Servlet 3.0, which means Tomcat 7 and later), you can
> write your own login-handler for these drive-by logins.
>
> (Actually, looking at the documentation for
> HttpServletRequest.login, it seems like this might not actually
> work (or if it does, it might violate the spec) since it says that
> getAuthType must return null in order for login() to be successful.
> That sounds to me like either the container is in total control, or
> the webapp is in total control. Hmm.)
>
> -chris
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
>
> http://www.gleichklang-mail.de: Der Email-Zugang für ökologisch
> und sozial denkende Menschen!
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSfVLaAAoJEBzwKT+lPKRYK7UP/0MUSJJvTiYnJ1RjzehRGSmG
oky4yx6kHcFJ/eJnl3MwdvZpmiI2+AZ6i9cwcHy9YkLMAwbegdnYMPAnmqMQrqDa
YybfcA877nbseqDrQnRDq2CM4E6KZU9zHypimuswBImHUF9dsqVrdotFx0iLI39y
JpAk1xnvM7GFxfqoJXomon0S9u0uxosHrB2soppyigMxyOlZhqsfLNMxoIyyb2C3
OrSRM0vVfM5oPfRfwYbinjhmw0TMxiQybZJxDFqbFO189GWomazmB1ygOTCmHIOe
i1yDw5GYJXcuNbBAfXnKWZFN6Tx7V0tK+4TQ1WR7U0w8amP9FYpaEL2a8o1daRLW
7YHMUqQDUs4hLcaF1BqeEq+cNbmIgCxTvDy3nY4qniGiKFWWjYz6HkIIIsLxP2Na
7UWxDVxlgaZlHF+ekQEV1gOyStNhUUZF9sv0fwhEHDnDbvgkRfCL7A77cJrCiEZl
qfVOor7iqhrOn7SnF4gq+5C1EPdPS96bWB8qrjyJ8u8W/DhT+FkB786rUPni6Sfu
KesR0KznjMSWmlNYQWMZwpOrZM0OPLG8//GFj0a8rHoiyvsygYLQwbsSYBIosX+J
nh04O07uwm7+/WdhaGtiC5dAihP3eLquevynAIl4QlqOH+RxDJuo12oSiPujq5I7
fjxFE3fNsElZri5fNSBy
=HGIu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session init problem since moving to new server/tomcat
Posted by Martin <ma...@gleichklang.de>.
Thank you Christopher for your in depth annotations. We just downgraded
from v6.0.34 to .20 and the problem has vanished. We obviously have some
changes to do before we can upgrade to v7 as far as the session handling
is concerned. Your post will help us along the way. Thanks again.
Martin
Am 2013-11-08 16:22, schrieb Christopher Schultz:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Martin,
>
> On 11/8/13, 9:59 AM, Martin wrote:
>> Recently we moved our application from an old ubuntu to a newer
>> centos box. We upgraded our JAVA version, tomcat (from v5 to latest
>> v6) and basically all server components.
>
> I would highly recommend that you upgrade directly to 7.0.x... moving
> from Tomcat 6 to Tomcat 7 is much easier than the transition from 5.0
> to 6.0. Make the investment, now. Tomcat 8 is just around the corner
> which means that Tomcat 6's days are numbered (though it may still
> have 1000 days left in its lifetime).
>
>> Local tests of our application showed no problems with these newer
>> versions, in fact it has been developed with these since quite
>> some time.
>>
>> But now we seem to have a problem with our session
>> management/creation, however only on the new live server, not
>> locally.
>>
>> Whenever a user visits a page (the login page) for the very first
>> time (no JSESSIONID-Cookie), the first login form submit does not
>> work. Our live application obviously encounters some kind of
>> unexpected stuff. The followup form submit works as expected. The
>> JSESSIONID is created on the first page load btw.
>
> What does your login <form> look like? Often, users forget to encode
> the session id in the URL for the form like this:
>
> <form action="j_security_check">
>
> It would be better to do this:
>
> <form action="<%= response.encoreURL(request.getContextPath() +
> "/j_security_check")) %>" />
>
> That way, Tomcat will get the session identifier whether cookies are
> in use or not.
>
>> The person who wrote this part of our application has gone AWOL
>> and locally we cannot reproduce this.
>>
>> Do you guys have any idea what could be responsible for this? I
>> obviously copied all the tomcat settings from the older version and
>> I cannot find anything worthy in the logs.
>
> Some things have changed from Tomcat 5 to Tomcat 6 and later,
> especially with session-handling during login. For example, Tomcat
> now
> switches session-ids after a successful login in order to protect
> against session-fixation attacks. Also, Tomcat now requires (though
> I'm not sure if this is different from the Tomcat 5 days) a session
> to
> be in place in order to show the login screen because it needs to
> store the original request somewhere for a post-authentication
> redirect.
>
> Are you using the "standard" spec-defined login process:
>
> 1. User requests a protected page
> 2. Container challenges user for credentials
> 3. User provides valid credentials
> 4. Container sends the user to the originally-requested resource
>
> ?
>
> Or, are you using what I call a drive-by login where you just have
> the
> login page showing in index.jsp or whatever with a login button? This
> last one won't work the way you expect it to work, because the spec
> (stupidly, IMO) didn't include a standard way for containers to
> handle
> "unsolicited" logins.
>
> These days (Servlet 3.0, which means Tomcat 7 and later), you can
> write your own login-handler for these drive-by logins.
>
> (Actually, looking at the documentation for HttpServletRequest.login,
> it seems like this might not actually work (or if it does, it might
> violate the spec) since it says that getAuthType must return null in
> order for login() to be successful. That sounds to me like either the
> container is in total control, or the webapp is in total control.
> Hmm.)
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSfQHIAAoJEBzwKT+lPKRY9OcQAMMMAIpVuFtUhwWv9sTbs0uK
> fnDB/VXVytAsYcbu4rVrgqiculcGP/2CkhZI2nle43FoPNZkMMbnJAr2AczYdV69
> MTEoBOeY5rPQiUKs89KCKUN6V0kQkkv+cBQOaMzbGDBYd7vMgpONh9LXKuZjMkKC
> iBpWdTRz1H79+82VpfGO7obVp+k3QXS4hLI/rMT3o01vacfQXJc6C0+vvmlFLTGH
> QCyU0NfRbeT2MPGBmCUabjLpf7S/kRv2d1l26Az6AYOZHm/s/Ee9+yyZ+MuXOsJk
> wEOX7/+jDcshQd1R+tiQdEyFJGCqKOgGbRJ5AwVRXyWXjgEUXj3YzXAmK7NrBF39
> bu8WQib8y8kOiIo7ME1YF+qNs6eXDqdeEyf9l2zh19L0P7jn43Y3vWvOaqI34kML
> 9BBsh32f6KD5BpW3fQ9WgG8Ssk+9TK/w6AkQvG7RYhSzuiQykJslvuYNrWCFR+Nf
> r8rDbqnLrcWPJ5RT19vyitJHIvNEIm3RKA/+bEfVQwBFMS4FEgiOqknEUU8m8VZD
> 1SxB8eXR2wfOA9H4BsSh7fmTFCneDZv8+h2Hntuf9IKe9fB4G8lU1RThH2gXl8rB
> tOSix5WKKadvuss42tpKtsOI2IaSObcK163pdZIc0QUHOFMZC/15wimRlGrW0vbL
> bF36rsMYpfhFG8naSZq5
> =mhI6
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
http://www.gleichklang-mail.de: Der Email-Zugang für ökologisch und sozial denkende Menschen!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session init problem since moving to new server/tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Martin,
On 11/8/13, 9:59 AM, Martin wrote:
> Recently we moved our application from an old ubuntu to a newer
> centos box. We upgraded our JAVA version, tomcat (from v5 to latest
> v6) and basically all server components.
I would highly recommend that you upgrade directly to 7.0.x... moving
from Tomcat 6 to Tomcat 7 is much easier than the transition from 5.0
to 6.0. Make the investment, now. Tomcat 8 is just around the corner
which means that Tomcat 6's days are numbered (though it may still
have 1000 days left in its lifetime).
> Local tests of our application showed no problems with these newer
> versions, in fact it has been developed with these since quite
> some time.
>
> But now we seem to have a problem with our session
> management/creation, however only on the new live server, not
> locally.
>
> Whenever a user visits a page (the login page) for the very first
> time (no JSESSIONID-Cookie), the first login form submit does not
> work. Our live application obviously encounters some kind of
> unexpected stuff. The followup form submit works as expected. The
> JSESSIONID is created on the first page load btw.
What does your login <form> look like? Often, users forget to encode
the session id in the URL for the form like this:
<form action="j_security_check">
It would be better to do this:
<form action="<%= response.encoreURL(request.getContextPath() +
"/j_security_check")) %>" />
That way, Tomcat will get the session identifier whether cookies are
in use or not.
> The person who wrote this part of our application has gone AWOL
> and locally we cannot reproduce this.
>
> Do you guys have any idea what could be responsible for this? I
> obviously copied all the tomcat settings from the older version and
> I cannot find anything worthy in the logs.
Some things have changed from Tomcat 5 to Tomcat 6 and later,
especially with session-handling during login. For example, Tomcat now
switches session-ids after a successful login in order to protect
against session-fixation attacks. Also, Tomcat now requires (though
I'm not sure if this is different from the Tomcat 5 days) a session to
be in place in order to show the login screen because it needs to
store the original request somewhere for a post-authentication redirect.
Are you using the "standard" spec-defined login process:
1. User requests a protected page
2. Container challenges user for credentials
3. User provides valid credentials
4. Container sends the user to the originally-requested resource
?
Or, are you using what I call a drive-by login where you just have the
login page showing in index.jsp or whatever with a login button? This
last one won't work the way you expect it to work, because the spec
(stupidly, IMO) didn't include a standard way for containers to handle
"unsolicited" logins.
These days (Servlet 3.0, which means Tomcat 7 and later), you can
write your own login-handler for these drive-by logins.
(Actually, looking at the documentation for HttpServletRequest.login,
it seems like this might not actually work (or if it does, it might
violate the spec) since it says that getAuthType must return null in
order for login() to be successful. That sounds to me like either the
container is in total control, or the webapp is in total control. Hmm.)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSfQHIAAoJEBzwKT+lPKRY9OcQAMMMAIpVuFtUhwWv9sTbs0uK
fnDB/VXVytAsYcbu4rVrgqiculcGP/2CkhZI2nle43FoPNZkMMbnJAr2AczYdV69
MTEoBOeY5rPQiUKs89KCKUN6V0kQkkv+cBQOaMzbGDBYd7vMgpONh9LXKuZjMkKC
iBpWdTRz1H79+82VpfGO7obVp+k3QXS4hLI/rMT3o01vacfQXJc6C0+vvmlFLTGH
QCyU0NfRbeT2MPGBmCUabjLpf7S/kRv2d1l26Az6AYOZHm/s/Ee9+yyZ+MuXOsJk
wEOX7/+jDcshQd1R+tiQdEyFJGCqKOgGbRJ5AwVRXyWXjgEUXj3YzXAmK7NrBF39
bu8WQib8y8kOiIo7ME1YF+qNs6eXDqdeEyf9l2zh19L0P7jn43Y3vWvOaqI34kML
9BBsh32f6KD5BpW3fQ9WgG8Ssk+9TK/w6AkQvG7RYhSzuiQykJslvuYNrWCFR+Nf
r8rDbqnLrcWPJ5RT19vyitJHIvNEIm3RKA/+bEfVQwBFMS4FEgiOqknEUU8m8VZD
1SxB8eXR2wfOA9H4BsSh7fmTFCneDZv8+h2Hntuf9IKe9fB4G8lU1RThH2gXl8rB
tOSix5WKKadvuss42tpKtsOI2IaSObcK163pdZIc0QUHOFMZC/15wimRlGrW0vbL
bF36rsMYpfhFG8naSZq5
=mhI6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org