[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


            Bug ID: 196592
           Summary: Cookies not sent with third party requests via XHR or
           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