tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin <>
Subject Re: Session init problem since moving to new server/tomcat
Date Fri, 08 Nov 2013 16:40:05 GMT
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.


Am 2013-11-08 16:22, schrieb Christopher Schultz:
> 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
> Version: GnuPG v1.4.15 (Darwin)
> Comment: GPGTools -
> Comment: Using GnuPG with Thunderbird -
> fnDB/VXVytAsYcbu4rVrgqiculcGP/2CkhZI2nle43FoPNZkMMbnJAr2AczYdV69
> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: Der Email-Zugang für ökologisch und sozial denkende Menschen!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message