Bug 188073 – Same-Site cookies are not sent with same-origin redirect initiated from cross-origin navigation

• Status: NEW
• Component: WebCore Misc.

[Daniel Bates]

Let A, B be two registrable domains where A != B. Without loss of generality suppose that you load A/a1.html in the top-most frame and it redirects to B/b1.html that redirects to A/a2.html that redirects to A/a3.html. Then same-site cookies are never sent in the request to A/a3.html. But we should have sent same-site cookies in the request to A/a3.html because the request is same-site with A/a2.html, which initiated the load.

[Radar WebKit Bug Importer]

<rdar://problem/42635007>

[Radar WebKit Bug Importer]

<rdar://problem/42635005>

[Daniel Bates]

Created attachment 345860 [details]
Layout tests

This bug is breaking our federated login. 

We have a somewhat tricky federated login setup between two trusted sites, and since Safari 12 there's a cookie not being sent with the last request - presumably due to ITP 2.0. 

Site A.example uses site B.example for federated login. Both sites are owned by the same entity, and know / trust each other (but not other sites) via shared secrets, and have split responsibilities - some account management is done on site A, some on site B (we have many sites A, this is to be able to reuse the functionality on B). 

The sequence is as follows: 

A.example renders page containing iframe from B.example (cookies not used or necessary). Form in this iframe has target=_top and action=B.example/login. User submits the form. 

B.example/login authenticates the login, sets a session cookie, and redirects to A.example/login?token=xyz 

A.example/login?token=xyz authenticates the login, sets a session cookie, and redirects to A.example/hello

A.example/hello expected the session cookie to be sent, but it isn't => looks like the user isn't logged in. <-- THIS IS THE CHANGE IN BEHAVIOR FROM PREVIOUS VERSIONS OF SAFARI.  

The user is terribly confused and either gives up or contacts support. 

If the user reloads A.example/hello or clicks a link on that page, the session cookie is sent => now it looks like the user is logged in. Even more confusing. 


Presumably this is due to ITP 2.0 (or similar functionality) blocking the cookie since it probably looks like a tracking scenario to that code - the user is logged in to both sites, so the ability to track is certainly there. 


Please include the session cookie when an eTLD redirects to itself (e.g. A.example/login?token=xyz redirecting to A.example/hello). It's totally fine if only cookies set in the redirecting action (A.example/login?token=xyz) are included.

Note that this does not reproduce when A.example is localhost - for some reason it only happens with "real" domains (or over https?)

It looks like the tests added in https://bugs.webkit.org/show_bug.cgi?id=185235 are insufficient since they use localhost.

[Daniel Bates]

This needs to be fixed in CFNetwork. This work is tracked in <rdar://problem/42097136>. Keeping this bug open to add tests.