New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 701319 link

Starred by 3 users
Status: WontFix
Owner: ----
Closed: May 2018
Cc:
█ mkwst@chromium.org
mmenke@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

chrome cannot set session id cookie correctly when two web applications use same domain

Reported by garychen...@gmail.com, Mar 14 2017 
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
We have two web applications use tomcat6 and they use the same domain(xxx.test.com),the first application visit by https,the other application visit by http.and they use the same sessionCookieName:JSESSIONID,but the path are not same(https:/ and http:/admin). when the first application visit successfully by https, chrome can set sessionid(JSESSIONID=xxxx),and now don't close the chrome,visit the second application by http,chrome cannot set sessionid with name JSESSIONID.but if we visit the second application by http first,two sessionid will set successfully.
1. clear the cookies
2. visit first web application "https://xxx.test.com" you will  find chrome can set sessionid(name:JSESSIONID, path:/) and don't close the chrome
3. visit second web application "http://xxx.test.com",you will find chrome cannot set sessionid(name:JSESSIONID, path:/admin) successfully.
4.if we visit the second web application first, two sessionid with the same name both can set successfully.

What is the expected behavior?
two sessionid can set successfully.

What went wrong?
we found chrome  can work normal with previous version. and firefox,Safari can also work normal 

Did this work before? N/A 

Chrome version: 56.0.2924.87  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

please check this issue.thanks

Comment 1 by mmenke@chromium.org, Mar 14 2017

Components: Internals>Network>Cookies
Status: Untriaged (was: Unconfirmed)
Note that due to a recent change, we don't allow non-secure cookies to overwrite or mask secure cookies, so if you set a set a secure cookie on https://admin.foo.com, and try to set a subdomain-matching cookie on http://foo.com with the same name, and  we won't allow you to set the second cookie.

Could you provide a net-internals log of both domains trying to set the cookies in question?  Instructions:  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

So we can see the cookies, uncheck the "Strip private information (cookies and credentials)" option.  To avoid any leaks of real cookies, you should run Chrome with an empty profile (Incognito mode is not enough).  To do this, run chrome with the command line "--user-data-dir=<some temp path>".

Comment 2 by mmenke@chromium.org, Mar 14 2017

Labels: Needs-Feedback

Comment 3 by garychen...@gmail.com, Mar 15 2017 

this is the net-internals log, thanks
net-internals-log.json
2.8 MB View Download

Comment 4 by mge...@chromium.org, Mar 16 2017

Labels: -Needs-Feedback

Comment 5 by mmenke@chromium.org, Apr 17 2017

Cc: mkwst@chromium.org mmenke@chromium.org
garychenqin:  Sorry, this dropped off my radar.  It looks like the HTTPS URL is setting the JSESSIONID cookie with a secure attribute, and then the HTTP URL is trying to overwrite it with an insecure cookie, something we currently don't allow.  Either they should be using different cookie names, or it should not be secure.

[+mkwst]:  We've run into a bunch of issues with this behavior change.  Should we make the issue more visible, or rethink the behavior?

Comment 6 by mmenke@chromium.org, May 2 2018

Status: WontFix (was: Untriaged)
Late to respond, but this is expected behavior, and required by spec.
►

Sign in to add a comment