http session not passed to websocket ws when before using wss
Reported by
michael....@googlemail.com,
Jul 27 2017
|
||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36 Steps to reproduce the problem: 1. Setup a webserver which serves https and http 2. Setup a test case as attached (see README.txt inside) 3. Open Chrome, request the https resource, afterwards request the http resource. Watch the tomcat console, httpSession is reported to be null! 4. If you first request http, then https and again http, it works fine (then http has http-session not null). What is the expected behavior? The httpSession object in case of http should be not null. But every reload of the http case, the http session is null. Only if you close and open the browser, then navigate to http, it is ok (not null). What went wrong? I assume that the http session object is not passed correctly to the websocket in case first https, then http. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 60.0.3112.78 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Does this feature work correctly in other browsers? - It works correctly in MSIE 11. - In Firefox same problem as in Chrome.
,
Jul 28 2017
,
Jul 28 2017
Nothing to do with HTTP...At least I assume "httpSession" is a websocket concept.
,
Jul 28 2017
I assume that httpSession is a variable inside Tomcat? The fact that it also doesn't work in Firefox implies that there something wrong with Tomcat rather than something wrong with Chrome. If you capture a Netlog dump as described in https://dev.chromium.org/for-testers/providing-network-details I will take a look at it. Actually, it would be better to capture two separate logs, https -> http and then http -> https in a fresh browser session. However, it is highly likely that whatever is happening is internal to Tomcat and the log won't contain anything unusual.
,
Jul 28 2017
httpSession is the variable in my testcase. I retrieve the javax.servlet.http.HttpSession from the javax.websocket.server.HandshakeRequest. For sure I will give it a try with jetty instead of tomcat and report here.
,
Jul 28 2017
Unfortunately jetty does not pass the httpsession in the javax.websocket.server.HandshakeRequest object (in jsr356 implementation). Can you point me to another container which I could use for this test? So I have created (for tomcat as container) Netlog dumps as requested, see attached 3 files.
,
Jul 29 2017
I reported this now as Tomcat Bug (#61360) with reference to here. Let's see if Tomcat developer are able to locate the problem.
,
Jul 31 2017
Here the answer from Tomcat developer Mark Thomas <markt@apache.org>: This is as a result of user agent behaviour. Tomcat marks the session cookie for sessions created under https as secure. This ensures that user agents do not send session IDs for secure sessions over http. In the http->https case - The first request creates a session and sets a non-secure session cookie - The browser sends this session cookie with the ws request - The second request continues to use the session cookie because sending a non-secure cookie over https is allowed - The wss request uses the non-secure session cookie for the same reason In the https->http case - The first request creates a session and sets a secure session cookie - The browser sends this session cookie with the wss request (since secure cookies can be sent with https requests) - The second request continues does not use the session cookie because sending a secure cookie over http is not allowed. Tomcat creates a new session and sends the user agent a non-secure cookie for that session - The user agent ignores this cookie (I'm guessing so that it doesn't over-write the secure one in case of a switch back to https) - The ws request is also sent without a session cookie. Hence the WebSocket handshake does not see a session.
,
Jul 31 2017
> - The user agent ignores this cookie (I'm guessing so that it doesn't over-write the secure one in case of a switch back to https) This is correct. If insecure cookies could overwrite secure ones it would be a security hole, so it is prevented. I had forgotten about this aspect. Sorry, but Chrome is working as intended here. My advice would be to always use wss:. If you can't do that, then try to use a different name for the cookie depending on whether it is a secure or insecure connection. |
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by nyerramilli@chromium.org
, Jul 28 2017