[Webkit-unassigned] [Bug 196592] New: Cookies not sent with third party requests via XHR or iFrame
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Apr 3 23:08:17 PDT 2019
https://bugs.webkit.org/show_bug.cgi?id=196592
Bug ID: 196592
Summary: Cookies not sent with third party requests via XHR or
iFrame
Product: WebKit
Version: Safari 12
Hardware: All
OS: All
Status: NEW
Severity: Major
Priority: P2
Component: Frames
Assignee: webkit-unassigned at lists.webkit.org
Reporter: sam at potts.es
Since Safari 12 we're seeing some strange issues with XHR requests which is effecting our SSO solution. Here's the flow we're using:
- User visits `my.example1.com` and logs in.
- User is then SSO'd to `example2.com`.
- `example2.com` will render a keep alive script that makes a client side request to `my.example1.com/path/to/page` either via XHR or a hidden `<iframe>` (with the required `sandbox` attribute properties) on every page load or periodically to keep the session alive and check that the user is authenticated; either by the resultant JSON in the XHR or a postMessage in the `<iframe>` method
- If user logs out of `my.example1.com`, they are logged out of `example2.com`
This was working great using XHR until Safari 12; then suddenly the auth cookies were no longer sent with this request so the user appeared to be unauthenticated. We then implemented a hidden `<iframe>` solution where it would hit a URL that would send a postMessage to the parent indicating if the user was authenticated. This seemed to work fine until a recent update of Safari in macOS 10.14.4 and now the `<iframe>` is rendered to the DOM but does not appear to load or make the request at all and thus no message is received by the parent. Chrome and Firefox still seem ok with the XHR method.
Ideally we'd like to use the XHR solution for all browsers to keep things simple.
We're at a loss and all we're getting is customer complaints as they are booted out of `example2.com` instantly after being redirected. At the moment we're just steering users away from Safari as a result. I really doubt this is an uncommon pattern.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190404/fd93bfcf/attachment.html>
More information about the webkit-unassigned
mailing list