| Summary: | Same-Site cookies are not sent with same-origin redirect initiated from cross-origin navigation | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Daniel Bates <dbates> | ||||
| Component: | WebCore Misc. | Assignee: | Daniel Bates <dbates> | ||||
| Status: | NEW --- | ||||||
| Severity: | Normal | CC: | jxtps435, webkit-bug-importer | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Mac | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Daniel Bates
2018-07-26 13:04:11 PDT
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. |