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

Issue 659554 link

Starred by 2 users

Issue metadata

Status: Archived
Owner: ----
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Cookies with Same Site Lax or Strict is not passed on same-site requests initiated from an anchor tag with the download attribute.

Reported by gustavni...@gmail.com, Oct 26 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce the problem:
1. You have a cookie that holds an auth token with a Same Site value of "Lax" (or "Strict).
2. On the website, you click a link that will download a resource. (<a href="foo.txt" download>Click here!</a>)

What is the expected behavior?
A request for foo.txt is sent with the cookie in the headers, as the resource that is requested to be downloaded is hosted on the same site.

What went wrong?
The cookie is not included in the request for foo.txt.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 54.0.2840.71  Channel: stable
OS Version: Ubuntu 16.04
Flash Version: Shockwave Flash 23.0 r0

I created a small node.js server that will illustrate the problem, comparing different values of Same Site on cookies and a tags with/without the download attribute.

https://github.com/gustavnikolaj/same-site-and-download-attribute
 
Cc: krajshree@chromium.org
Labels: Needs-Feedback
gustavnikolaj@ -Thanks for filing this issue...!!

Could you please provide a sample URL to test this issue.
This will help us in triaging the issue further.

Thanks...!!

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

Cc: mkwst@chromium.org mmenke@chromium.org
Components: UI>Browser>Downloads Internals>Network>Cookies

Comment 3 by mmenke@chromium.org, Mar 17 2017

This is an olrder issue, but I assume it still repros, unless the downloads code has been modified to set both first_party_for_cookies and initiator for the request.
Yes, still reproducible in Chrome 56.0.2924.87 on Linux

Comment 5 by mmenke@chromium.org, Mar 20 2017

[mkwst]:  Looks like initiator is being set from the downloads code (https://cs.chromium.org/chromium/src/content/browser/download/download_request_core.cc?gsn=CreateRequestOnIOThread&l=220), so I'm not sure what's happening.
Not sure why the Needs-Feedback label is still there. The server code in the github repo referenced by the OP clearly demonstrates the issue. Is it really necessary to put it online at a public url?

Comment 7 by mmenke@chromium.org, Apr 20 2017

I can't reproduce this.  I just replaced the body of https://www.google.com with '<a download href="/">foo</a>', and we correctly decide to include same-site cookies (Strict and Lax) in the request.  (I'm not going to download and install node js binaries or run the above script on my corp PC).
I have deployed it here: https://samesitelax-cookie-sunbokbslb.now.sh/

It's still reproducible in at least version 54, 55, and 56, but it is fixed in version 57.
Project Member

Comment 9 by sheriffbot@chromium.org, Apr 21 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Archived (was: Unconfirmed)
Thanks,for the help, Gustav!  The fact it's working in Chrome 57 would explain why the code looked correct, and why I couldn't repro locally.  Given that M57 has been on stable channel for about 6 weeks, and M58 is coming out soon, I'm going to go ahead and archive this issue, since it looks to be fixed.

Sign in to add a comment