Bug 188073

<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.