> -----Original Message-----
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Monday, July 29, 2013 8:21 PM
> To: Tomcat Users List
> Subject: Re: secure cookies
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jeffrey,
>
> On 7/29/13 4:09 PM, Jeffrey Janner wrote:
> > Thanks for the verification, Mark. I was under the impression you'd
> > only want to [set secure="true"] if you were already front-ending the
> > site with something that was doing the SSL for you (e.g. httpd or a
> > proxy), and the server spoke HTTP between each other.
>
> We use secure="true" for loopback-only connectors to avoid the overhead
> of SSL when we know the requests are going to come from localhost (we
> have Apache Cocoon running in a separate JVM calling-back to our main
> webapp for some XML). So there are some non-fronting use cases, too.
>
> (Note that mod_jk already sets the "secure" flag with each request if
> the original request to httpd came over HTTPS.)
>
> > Our app accepts an initial request to the login page on HTTP, but
> > should be automatically routed to the HTTPS connector due to
> > <transport-guarantee> before the page is actually sent back. Then we
> > actually invalidate the session and create a new on successful login,
> > and that session/cookie is used for the rest of the user's time on
> the
> > site. So all I really need to do to implement at 6.x is the context
> > change.
>
> Tomcat changes the session id (without actually destroying the
> session) after authentication, so if you are using Tomcat's
> authentication, then there is no need for the invalidation you describe
> above.
>
We don't use Tomcat Auth, though I'm arguing for changing to Tomcat w/Form Auth
so it's easier to support 2-factor auth for those customers who insist on it.
I'm not sure of the exact methodology employed, but I'm sure it's similar.
