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

Issue 692655 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Wildcard/subdomain cookies are not accepted

Reported by gel...@gmail.com, Feb 15 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
1. Visit https://login-with.now.sh
2. Press TRY and login with the account of your choice
3. You will be redirected to https://login-with.now.sh BUT no "welcome back" message is visible

What is the expected behavior?
After logging in, you are supposed to a "welcome back" message.
Two cookies "jwt" and "profile" should be visible in dev console.

What went wrong?
The cookie header response from https://login.now.sh is getting ignored/refused.

Did this work before? Yes 55

Does this work in other browsers? Yes

Chrome version: 56.0.2924.87  Channel: stable
OS Version: OS X 10.12.2
Flash Version: Shockwave Flash 24.0 r0

Safari, Firefox and Edge are accepting the cookies.

 
Screen Shot 2017-02-12 at 16.12.21.png
312 KB View Download
Components: Internals>Network>Cookies
Labels: Needs-Bisect Needs-Triage-M56
Labels: -Needs-Bisect -Needs-Triage-M56 OS-Linux
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Mac-10.12.2 and Linux Ubuntu-14.04 using chrome stable version 	56.0.2924.87 and canary 58.0.3014.0.
This is regression issue broken in M56. Please find the bisect information as below
Narrow Bisect::
===============
Good::56.0.2924.22  
Bad:: 56.0.2924.24    
ChangeLog from Omahaproxy: 
=========== 
https://chromium.googlesource.com/chromium/src/+log/56.0.2924.22..56.0.2924.24?pretty=fuller&n=10000  

Unable to find the suspect from above CL. Could some one from dev team please help in assigning it to right owner.

Note:Issue not observed in Windows-7
Thanks. 

Comment 4 by roy...@google.com, Mar 25 2017

Labels: -Pri-2 M-57 Hotlist-Enterprise Pri-1
Owner: gov...@chromium.org
This is a recent regression between 55/56. Can we get help to fix it ?

Comment 5 by gov...@chromium.org, Mar 26 2017

Cc: ligim...@chromium.org
Labels: -M-57 ReleaseBlock-Stable M-58
Owner: ----
It is too late to get this fix in for M57. Moving to M58. 
Ligi, could you please try to find right dev owner for this?
Cc: nyerramilli@chromium.org sureshkumari@chromium.org
Labels: Needs-Bisect
sureshkumari@ , please try a per revision bisect.
Labels: -Needs-Bisect
Owner: rsleevi@chromium.org
(Cancelling the Needs-Bisect request as I think I found the culprit)

This actually looks intentional.
The latest public suffix list update adds now.sh as an effective top level domain, since apparently every sub domain of it hosts content by a different author.
https://chromium.googlesource.com/chromium/src/+/d81b12d08c29a8a6d8d9434d4d1d2d0c14230d53%5E%21/

This is done for security reasons (authors cannot change or get cookies of the main domain).

My guess is that this is a WontFix.
Status: WontFix (was: Untriaged)
Thanks phistuck! Yup, this is WontFix - adding now.sh means that login-with.now.sh and login.now.sh are two separate cookie domains, and that neither can set cookies for now.sh

Considering this request was made the now.sh domain operator, and consistent across browsers that have since taken that update (Firefox and Chrome, eventually Safari and Edge), closing as WontFix/WorkingAsIntended.

Sign in to add a comment