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.
<rdar://problem/42635007>
<rdar://problem/42635005>
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.
This needs to be fixed in CFNetwork. This work is tracked in <rdar://problem/42097136>. Keeping this bug open to add tests.