tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Session lost when switching from https to http after upgrade to Tomcat 6
Date Sun, 08 Jun 2008 09:35:38 GMT
thank you for the explanations below.  And I apologise if I answered 
rather testily before.

Mark Thomas wrote:
> André Warnier wrote:
>> Mark Thomas wrote:
>>> André Warnier wrote:
>>>> A lot of speculation here, but who knows ?
>>> Indeed. And it is all wrong.
>> Is that proven, or mere speculation on your part ?
> That is fact. In the cases where Tomcat does do an internal redirect it 
> uses a RequestDispatcher.forward()
>>>> To my knowledge, there exists no case where the browser would not 
>>>> send a cookie with every request, if it has it and it is valid.
>>> Well, there is the obvious example Rainer has already given of 
>>> cookies marked as secure. 
>> Which I mentioned, as one of the cases where a browser would not send 
>> the cookie.  But I don't think that a cookie sent by the browser over 
>> a secure connection is necessarily marked as "secure".  That is a 
>> attribute of the cookie, decided by the cookie creator.
> The OP is asking about the session cookie which is created by Tomcat. 
> When the session is created under https, the cookie is marked as secure.
>> Given that the session is created under https this is
>>> probably what is happening. Sessions are not maintained in 
>>> transitions from https to http.
>> I think that you may err here.  Are you not confusing sessions and 
>> cookies ?
> This is just semantics. The cookie is secure. A secure cookie will not 
> be sent over http. From both the user's and the application's 
> perspective the session is lost.
>> Is is really the session that is gone at the server side ?
> No. It is still there. Switching back to https should restore the session.
>> Or is it that the session is still there, but the absence (in the 
>> browser request) of the cookie containing the session-id does not 
>> allow the server to reconnect the  request with the still-existing 
>> session ?
>> I thought that this last was the problem originally mentioned.
> That sums it up pretty well.
>> It must be easy to distinguish between these two cases at the server 
>> side : either there is no cookie, or there is a cookie but the 
>> cookie-id it contains does not allow to reconnect validly to an 
>> existing session.
>> Which is it ?
> It is the first. There is no cookie sent from the browser.
>> There is something else that tickles my memory : in a previous 
>> message, krusek said : "For clarity,  Apache 2 is handling SSL not 
>> tomcat.  "
>> If so, does Tomcat even know that there is an SSL/HTTPS part ?
> Yes. mod_jk passes that info along. It will also pass on any client 
> certificates if httpd has been configured for certificate authentication.
>> I mean, the connection between Apache and Tomcat via mod_jk, if they 
>> are all on the same host, has no particular reason to be SSL, or is it ?
> The connection uses the AJP protocol. mod_jk doesn't support any form of 
> encryption for this link. There are ways of encrypting this if you need to.
>>> If you need to protect the session creation with https then you 
>>> should almost certainly be providing the same level of protection for 
>>> the session ID.
>> Well, not necessarily.  I know you refer to a previous thread 
>> somewhere, but I beg to differ.  You may be wanting to protect via 
>> HTTPS the exchange of a user-id and password over the Internet.  But 
>> once that is done, the session data on the server probably contains 
>> other elements, sufficient to ensure that it is not someone else 
>> sending this same session-id.
> This could be implemented by the application but usually isn't. The most 
> often referred to solution uses the client IP as an added check. The 
> problem is that some clients (as a result of the ISP they are using) 
> change IP with every request.
Off-topic : Are you sure that can really happen ? I must admit that I 
have never seen that behaviour before, and it seems to me that it would 
create a host of other problems (such as breaking the underlying TCP 

>> The application may be trivial, but not the user's password.
> If the functionality is important enough to protect with a password over 
> SSL then the session ID, which for most applications will give access to 
> that functionality, should usually be protected in the same way. There 
> will be some exceptions to this. Protected the session by other means is 
> one possibility.
> To get back to the OPs question. The behaviour seen is entirely 
> expected. Like Len, I am more concerned that it wasn't seen in previous 
> versions.

Without meaning any disrespect to anyone, it is in my experience a 
rather frequent occurrence that someone would say that "nothing else 
than a xxx update was made, and the consequence is yyy", and 
overlook/not think it important to mention, that something else was also 
done simultaneously.  I have been guilty of the same sin.

Since according to Mark's explanation above, there is a rational 
explanation of why the session-id-bearing cookies, although present in 
the browser cache, are not being sent anymore after the session switches 
back from HTTPS to HTTP, and since that behaviour is not new and has in 
fact nothing to do with Tomcat directly, the logical inference is that 
there must have been something else changed compared to before, when it 
was working.

In other words, original submitter, out with it : what else apart from 
the Tomcat update was done ?  Was the session pages layout, ever so 
slightly, also modified maybe ?


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message