tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Forward <>
Subject Re: How do I turn off secure cookies for session IDs?
Date Fri, 23 Jan 2004 22:43:12 GMT
On Fri, 23 Jan 2004 13:15:18 -0800, Justin Ruthenbeck
<> wrote:

>At 12:59 PM 1/23/2004, you wrote:
>>The Problem
>>   The login page creates a session and sets a cookie as follows:
>>Set-Cookie: JSESSIONID=A26A878059077E1ABEE058A62541957C; Path=/; Secure
>>   The "Secure" on the end tells the web browser NOT to send the cookie 
>> back to
>>the server unless it is an SSL connection. When the user is redirected 
>>to the
>>next non-SSL page, no cookie is sent back to the server, a new session is
>>created, and a new cookie is set as follows:
>>Set-Cookie: JSESSIONID=082E4CACA42D045D7E1F1F55CB073C48; Path=/
>>   My application, assuming the user is not logged in, redirects the 
>> user back to
>>the main page. There is an existing session, so it is used for the login
>>variable. Since the cookie is no longer labeled "Secure" it is valid for 
>>Possible Solutions
>>   This is where I need some help. If it is simply a configuration 
>> setting, I
>>have missed it. Otherwise I need to make sure a non-secure cookie exists 
>>displaying the login page. This could mean redirecting to a non-SSL page 
>>if the session is new or somehow grabbing the Cookie object before it is 
>>sent to
>>the browser and calling setSecure(false), neither of which seem like an 
>The general problem that you're hitting here is that you shouldn't/can't 
>start a session over a secure connection, then use the same session for 
>non-secure communication (this is logical and necessary).  In this case, 
>you don't want a secure session -- you want only the l/p to be transfered 
>more securely.
>The general solution, as you suggested, is to start the session over an 
>insecure connection to establish it as insecure.  After the session has 
>been started, authenticate (more) securely and then continue to use the 
>same session when you switch back to insecure comm.
>Note, of course, that starting a session with an insecure connection 
>makes it vulnerable when you switch over to secure.  Presumably, however, 
>you're not *that* worried about the implications of this and are more 
>interested in hiding the l/p from curious eyes.
>Justin Ruthenbeck
>Software Engineer, NextEngine Inc.
>justinr - AT - nextengine DOT com
>Confidential. See:

  Thanks for your quick response, Justin. It was not the answer I
wanted, but prompted me to find a workaround. I can understand why one
would usually want a secure cookie, but I would think it would be a
configurable option. This behavior is not exhibited when running
Apache in front of Tomcat or when using URL rewriting for session
management. It only exhibits itself when using Tomcat by itself with
SSL and cookies turned on.

  I found a workaround: I can set an identical JSESSIONID cookie
without the secure setting and it propagates, but now my web
application is Tomcat-specific.

  If anyone knows of a better method, I would sure appreciate hearing
about it.


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

View raw message