Ok here we go, I have worked a bit through this and created a PoC:

http://pastebin.com/ENiwCVdC

I discovered while this, that this bug only occurs if you are being redirected from a *foreign* site. It doesn ot occur if you're being redirected from the same site. So the conditions are fairly strange to when this occur. I have had a version of the PoC offering you a link to http://127.0.0.1:8000, but this ended up in the cookies being available again.

Hope this helps, if I can do anything else for you, please let me know.

CCing dev from  issue 150066  , for further inputs on this.

Thanks!

@ markusheintz : Could you please take a look in to this issue.

Thank you!

Any progress here yet?

Is anyone working on this?

Hi there, I am also having the same issue while sending the cookie in response with 302 redirect, I am using the Identity Server 3

I ran in to this same issue. Explicitly setting `path=/` was enough to get the cookie to persist. Without the `path` directive it would not persist.

After testing this a little more, I was redirecting from `/oauth/google` to `/` which won't save the cookie without setting `path=/`. If I instead redirect from `/oauth/google` to `/oauth/login` without setting the path directive then it _does_ save the cookie under the `/oauth` path.

Looking at the original bug report, they were redirecting from `/login` to `/profile` which would explain why it wasn't saved (assuming the path directive wasn't set).

I am experiencing this same problem, in an ASP.NET Core 2 application.
I spent a few hours on this issue before finding this post.

PoC:
User visits https://mysite.example.com/Login

        [HttpGet]
        [AllowAnonymous]
        public IActionResult Login()
        {
            HttpContext.Session.SetString("Foo", "Bar");
            return Redirect("https://external.site.example.com/);
        }

mysite.example.com has now redirected the user to https://external.site.example.com/
...some (short) time later...
JavaScript on https://external.site.example.com/ issues a POST against https://mysite.example.com/

        [HttpPost]
        public string Index()
        {
            return HttpContext.Session.GetString("Foo");
        }

Index() returns null, as no cookie exists with a value for the key "Foo".

This is an issue because the above PoC is a simplified excerpt from an implementation of a popular pattern which is used to detect session hijacking when using third party authentication services which authenticate SmartCard users.

I know some websites which use this pattern are, as of now, displaying messages that Chrome is not currently a supported browser.

To add to my previous post.
I experienced the problem on "Version 61.0.3163.100 (Official Build) (64-bit)" running on Windows 10.

Seems it is out of scope from TE end, adding TE-NeedsTraige-help label to move this out of our triaging bucket.

Could someone from dev team please take a look into this issue.
Thanks..!

I have the same problem in Chrome 62.0.3202.75 (Official Build) (64-bit). The cookie (path=/; secure; samesite=strict; httponly) set during 302, 303 or 307 redirect is not send with the following request. When I hit the refresh button the cookie is send as expected.

 Issue 793840  has been merged into this issue.

Is this issue confirmed? In this case, we can update the status from "Unconfirmed" to "Available".

Available and unowned is a black hole.

Regardless, in my own testing, it looks like 302 redirects on the main frame can successfully set cookies, so I can't confirm it.

Issue 786114 (Access restricted to Google employees, for reasons, due to having a user's log) hints that the issue may be related to subframes, which means it may be a duplicate of  issue 793648  (Which has a fix that is currently rolling out to stable).

Yes, it looks like a duplicate of issue 786114 (and maybe issue 793643 too). However,  issue 793648  is WebView specific and the two patches will not fix this one.

FYI: I tried the script in comment 1 and I was not able to reproduce the bug.
I made some quick tests [here](https://chromium-review.googlesource.com/c/chromium/src/+/840010).
It seems to work whatever I try.

I can't confirm the bug.

I can confirm this bug.

When setting a cookie on 302 redirect with the following attributes the cookie will NOT be presented in the GET against the relative URL provided by the location header (/):
 * Secure
 * Http-Only
 * Expiration Not Set
 * SameSite Policy: Strict
 * Path /

If I change the samesite policy to lax, everything works fine.

Thanks reifymichael@!
Unfortunately I can't reproduce. I wrote a test that does what you described here:
https://chromium-review.googlesource.com/846984
The test passes on trunk (maybe it was fixed in the meantime?)

reifymichael@: Could you please tell me what I forgot to do to reproduce the bug?
FYI, The test does:
* navigate to https:/example.test/a.
* https:/example.test/a: 302 redirect to /b and "Set-Cookie: a=a;Secure;HttpOnly;SameSite=strict;Path=/"
* https:/example.test/b: Check for the "a=a" cookie.

+CC clamy FYI.

@reifmichael: Ping on c#24?  Hoping to get your assistance to move this bug forward.

I believe I've isolated some more conditions required to trigger this issue.

Key findings:

* The flow needs to start with a 303, if you start with a 302 this issue is not triggered (I note the test case suggested a few days back started with a 302); and
* The initial request has to be made to a https endpoint, starting the response flow below from a http endpoint did not trigger the issue.

The response flow that I finally used to reliably replicate this issue was:

1. 303 See Other (In my case different domains, not sure if this is relevant)
2. 302 Found (response contains Set-Cookie)
3. 500 Internal Server Error (this may vary but for my situation not sending the cookie provided in step 2 in the subsequent request is a fatal error).

My Set-Cookie header in response 2 looks like this:

Set-Cookie:_x_y_z=DkYXK6i6rkz_rm98u-mjeMVjPtSP2xCmsohn2KDC29zNM11h40HipeJ7E4eWaEq2Ar3qpOWNdeH4z-emkNGtrw; Secure; HttpOnly; SameSite=Strict; Path=/

As a temporary work around changing my Set-Cookie header to the following, note Lax per above commenter, prevents the issue from being triggered:

Set-Cookie:_x_y_z=qWXlf-IC_mZbj98vqdJ8fRFgIdEwfhlVpiafD9an5083vIJQUvYgxEFIRziEuEFk2C45RZXvUngrBfjEYg0w2Q; Secure; HttpOnly; SameSite=Lax; Path=/

I hope that is somewhat helpful in finding root cause here.

Chrome Version 63.0.3239.132 (Official Build) (64-bit)
OSX Version 10.13.2

Thanks bradleybeddoes@!
Unfortunately, I am still not able to reproduce anything.

I am not sure to understand what are your repro step. Here is what I understood:

Request      | Response
-------------------------------------------------------------------
1) "a.com/"  | 303 See Other; Location: "b.com/1"
2) "b.com/1" | 302 Found; Location: "b.com/2"; Set-cookie <cookie>[1]
3) "b.com/2  | 500 Internal Server Error ???

[1] With cookie="a=a;Secure;HttpOnly;SameSite=strict;Path=/"

I was not able to test HTTPS on more than 1 domain for the moment.
Here is the associated test: https://chromium-review.googlesource.com/870491

Please let us know what to do to reproduce the issue.
 
FYI: I my first regression test, I also tried to replace 302 (HTTP_FOUND) by 303 (HTTP_SEE_OTHER). It didn't changed the output (cookie are sent).

Chrome Version: (master) 65.0.3323.0 (Developer Build) (64-bit)

Hi arthursonzogni@ - Your table is correct, in my case the 500 is thrown by the application because the cookie is missing.

I went back to do some more testing for you earlier this morning (I was going to assert if http/https really did make any difference for request 1) but I can no longer make this issue trigger in my development environment. This is very puzzling because I could very reliably trigger it last night. 

There has to be something environmental that I'm not considering which has caused the issue to no longer appear in my development environment but I can't seem to determine what it is.

I can still make the issue trigger when using the same Chrome instance against the deployed production code. I've again studied the request flow and apart from some keep-alive headers and the use of EV certificates it seems identical to what I have in development (Yes I did roll development back to the same code version as is in production without the SameSite=Lax fix).

I'll update once we push SameSite=Lax to production to (hopefully) confirm this change fixed the issue there.

Any updates on this issue?

On my side, I made in comment 22,24 and 27 tests reproducing what the reporter(s) described:
* https://chromium-review.googlesource.com/c/chromium/src/+/840010
* https://chromium-review.googlesource.com/c/chromium/src/+/846984
* https://chromium-review.googlesource.com/c/chromium/src/+/870491
There was no issue in all of them (WAI).

I am waiting for new reproduction steps from reporter(s), if any.

Closing because of inactivity. Please reopen if you can provide the requested information.

Hello,

We've encountered this issue, but its very sporadic. 

The overwhelming majority of the time, we find when:

1) User navigates to a "change account" URL
2) We Set-Cookie with a new value for a "current account" cookie
3) In the same Set-Cookie response, we also issue a temporary redirect to the home page

Pretty much every time, this works. A colleague in my office can hit the issue described (previous/old cookie value used when loading the redirected-to page, instead of the value in the Set-Cookie response).

We haven't been able to reproduce reliably yet.

It feels like a race condition, somewhere between "Set-Cookie" being parsed by Chrome, and at the same moment, following the Location redirect to the new location.

Sometimes, I think the Location redirect begins to be followed before the Set-Cookie was completely processed. Is that possible?

Another thought based on the discussion around "Lax" having an affect, is perhaps the set-cookie not being considered for the Location redirect, due to a race condition in what determines whether a cookie passes the "Strict" (default) test?

Cookies are generally set synchronously on the in-memory cookie cache, though there is some weirdness if we haven't loaded the entire cookie database into memory yet ( issue 809178 ).  Wonder if this may be related, though we should also block the next request on setting cookies, if we can set them immediately.

@mmenke I don't have an environment setup to build Chrome from source; but is there something I can do to try and exacerbate the likelihood of any issue and then try and reproduce?

For example, you mentioned that there is weirdness if the entire cookie database isn't in memory yet. Any way I can make that happen more often than not, to then see if I can reliably reproduce the problem?

Cheers

PS: This bug is occurring on Mac OSX as well.

Without a repro, it's not even clear if what's occurring is expected or not, I don't have enough information to reproduce (I tried to repro and failed).  This could even be expected behavior - these could be uncredentialed cross-site requests, and the redirect not actually relevant.  Or you could have third party cookie blocking enabled (Or an extension that blocks third party cookies).

Without a string to start tugging on, it would orders of magnitude more time to investigate, and given that it's unclear if something is going wrong, seems not worth digging into.

Hi @mmenke,

Understood; its a bit confusing, but I think this is an intermittent bug.

We can eliminate 3rd party cookies being the issue; in this case, its our actual website (that does the redirect) that you are interacting with, that is doing the redirect and issuing a cookie, and which experiences the problem.

I'll see if I can put together a test case and be able to reproduce this reliably.

Happening also on OSX 66.0.3359.117. In my setup it works 100% consistently every time. The Set-Cookie is emitted on the same response as a 302 redirect. The redirect location is the same host/port/protocol as the request the 302 responded from. This is happening as part of a SAML SSO flow. It looks exactly like this:

Set-Cookie: Authorization=<cookieValue>; Max-Age=300; Path=/; SameSite=Strict; HttpOnly


Changing "Strict" to "Lax" immediately works around the issue.

What kind of requests are these?  XHRs?  Main frame request?  Subframe requests?  Image requests?  HTTPS, I assume.

In my case, it affects xhr and regular requests.

HTTPs yes. As a bigger example, sometimes after the redirect, our main frame page has used the old cookie (page nav bar header was not updated to reflect new cookie’s account), and sometimes the XHR itself that loads async when the main frame loads after the redirect, it returns data based on the old cookie value.

Have not yet seen both happen on the same page load but that could just be due to chance.

For me, HTTPS main document requests.

Adding Windows and Mac per comments #14 and #37.

I can reproduce the same bug on Windows 10/Chrome 67.0.3396.87. 
Scenario works fine in IE and Firefox.

Would a small ASP.NET Core reproduction solution be helpful? If so, I could make one

I'd like to see a repro (even so we can verify after Chrome updates that its fixed) if you're able to provide one Jonathan. We haven't had the moment to try and repro this in isolation yet.

I'm facing the same issue and I was able to reproduce (or not) in a "consistent" way, what I mean is that I have a website that sets a cookie in the same response that makes a redirect and the bug is present and the cookie wasn't set, but the same website, in a local environtment works as expected. I both cases the behavior is always the same, in production the cookie get lost always, and in my local environment works always. 

I can't provide you with the source code, because it's a propietary site, but I may show you the requests and responses from both cases (text file attached).

WORKING
=======

>>>>> [1] Request
POST /login HTTP/1.1
Host: clubdelbarril.loc
Connection: keep-alive
Content-Length: 57
Pragma: no-cache
Cache-Control: no-cache
Origin: http://clubdelbarril.loc
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/66.0.3359.181 Chrome/66.0.3359.181 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://clubdelbarril.loc/login
Accept-Encoding: gzip, deflate
Accept-Language: es-419,es;q=0.9,en;q=0.8
Cookie: _ga=GA1.2.976302707.1529615526; _gid=GA1.2.1137888380.1529954321; _gat=1

<<<<<< [2] Response
HTTP/1.1 302 Found
Server: nginx/1.13.6
Date: Mon, 25 Jun 2018 19:27:47 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/7.0.25
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: CAKEPHP=fcdaf2596416058c9c3289f8d6d1c533; path=/; HttpOnly
Location: http://clubdelbarril.loc/login-redirect
X-DEBUGKIT-ID: 5d31cd0f-8ec1-4124-910d-78fc15692f93

>>>>>> [3] Request
GET /login-redirect HTTP/1.1
Host: clubdelbarril.loc
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/66.0.3359.181 Chrome/66.0.3359.181 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://clubdelbarril.loc/login
Accept-Encoding: gzip, deflate
Accept-Language: es-419,es;q=0.9,en;q=0.8
Cookie: _ga=GA1.2.976302707.1529615526; _gid=GA1.2.1137888380.1529954321; _gat=1; CAKEPHP=fcdaf2596416058c9c3289f8d6d1c533

[2] sets the CAKEPHP cookie and in [3] it's present


NOT WORKING
===========

>>>> [1] Request
POST /login HTTP/1.1
Host: dev.clubdelbarril.com
Connection: keep-alive
Content-Length: 57
Pragma: no-cache
Cache-Control: no-cache
Authorization: Basic ********************* 
Origin: http://dev.clubdelbarril.com
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/66.0.3359.181 Chrome/66.0.3359.181 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://dev.clubdelbarril.com/login
Accept-Encoding: gzip, deflate
Accept-Language: es-419,es;q=0.9,en;q=0.8
Cookie: _ga=GA1.2.532878263.1527627898; _gid=GA1.2.1103331860.1529953358

<<<<< [2] Response
HTTP/1.1 302 Found
Date: Mon, 25 Jun 2018 19:30:34 GMT
Server: Apache
X-Powered-By: PHP/7.0.30
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-DEBUGKIT-ID: efa1f5e6-0ad5-4e71-89c5-4685e1931fda
Set-Cookie: CAKEPHP=amecctouusqkhao6hhajsoch55; path=/; HttpOnly
Location: http://dev.clubdelbarril.com/login-redirect
X-Powered-By: PleskLin
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

>>>>>> [3] Request
GET /login-redirect HTTP/1.1
Host: dev.clubdelbarril.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Authorization: Basic **************************
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/66.0.3359.181 Chrome/66.0.3359.181 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://dev.clubdelbarril.com/login
Accept-Encoding: gzip, deflate
Accept-Language: es-419,es;q=0.9,en;q=0.8
Cookie: _ga=GA1.2.532878263.1527627898; _gid=GA1.2.1103331860.1529953358

As you can see, [2] sets the cookie, but then in [3] it is not present.
(*) This example has Authorization basic headers because website is protected, I've replaced credentials with ***, but in the production env, without Authorization basic protection I've the same issue over http, I've forced it to use https as a workaround, because it's works ok over https.
I've no idea what's the difference between those requests that makes it work in the first case, but the behavior is consistent, it always works in local environment, and it's always fails in the dev online environment.

In my last comment I've miss the browser info, those request were captured using:

Chromium browser
Versión 66.0.3359.181 (Build oficial) Built on Ubuntu , running on Ubuntu 16.04 (64 bits)

But I also have to say that the issue was reported by many of our users, using different versions of google chrome. In firefox always works ok in every environment.

I have same Problem that Chrome 67.0.3396.87 on MacOS loos Coookie after redirect double.

My flow is:
1. Open Site with Key with _blank Tab from MailCatcher.
2. Key verification and on success set Cookie and redirect to Account.

After redirect Chrome loose cookie in after Step 2. My System redirect me to loggin page.

But if i Open URL with Key directly. It works. And if i set sameSite from "Strict" to "Lax" it works to.

Sorry to jump in here.

I ran across this thread while troubleshooting a similar issue. I was going through the steps to create a repo (https://github.com/daniefer/ChromiumBug) to link an example of this behavior when I "think" I found the solution.

If you at any point send a secure cookie to that domain and try to set the cookie at a later point over http with or without the secure option, the browser will ignore the cookie. This is presumably because the domain-cookie-name combo was marked as secure only, so you cannot set the cookie over http until you send a cookie again over https without the secure option. 

Does this help at all and does that behavior sound correct? I cannot produce this functionality in Fire Fox and have not gotten to testing in other browsers yet. 

re: comment #55: That sounds like https://www.chromestatus.com/feature/4506322921848832 
?

I am also running into this issue but only on Chromium. Chrome seems to work fine.

We are running an IdP for Gsuite and while debugging I found in Chromium when redirecting back to "https://www.google.com/a/<company-name>/acs" after login we encounter a redirect loop because the cookie is not read.

I noticed the default cookie settings in Chromium is not the same as Chrome. When I switched "Block third-party cookies: Prevent third-party websites from saving and reading cookie data" to match Chrome (off is the default in Chrome) I am not longer experiencing this issue in Chromium.

I've recently encountered this issue and traced the root cause back to the prefetch mechanism. It seems that multiple paths can trigger this behavior. 

One sure way I found to confirm if prefetch or caching is the issue is by using DevTools Inspector to set "Disable Cache".


Issue:

Observed that when MANUALLY TYPING a URL the browser transparently triggers a prefetch to '/'. 

(This prefetch does not happen when performing a copy/paste or selecting a favorite and the prefetch does not appear in the DevTools Inspector)

Upon initiating the request from a non-authorized state the response is a 302 redirect to the IdP. After successful authentication, the 302 with a Set-Cookie header back to the requested resource would occur. If the browser had previously prefetched the resource (in this case '/') it will return content from the cache and ignore the Set-Cookie header. This caused a auth failure due to the missing cookie.


Solution:

Add header 'Cache-Control: no-cache, no-store, max-age=0, must-revalidate' to the Response.


Was very difficult to root cause due to the seeming "intermittent" behavior. Once I caught the fact that a prefetch was happening and then noticed the the browser was using cached content later in the flow the problem was quickly resolved.


Solution:

Adding the 'Cache-Control' header definitely works however it seems to me that the browser should NOT ignore 'Set-Cookie' even if it is using the cache. I have not looked at the code directly but perhaps someone familiar with that part of the code can propose a fix or explain this behavior.

Hope these details help someone.

Best,
JW

Sounds like it's working as anticipated - if a redirect sets cookies that are required by where it redirects to, the redirect should be marked as not cachable.  Whatever code triggers the prefetch (Either omnibox code, or whatever browser-side prefetch code we now have) presumably disables saving cookies for the prefetch to avoid mutating a site's state.