Safari 13+ iframe 阻止 CORS cookie

Question

Safari 完全不允许您在与父域不同的域的 iframe 中设置 cookie，该死的服务器端 CORS 标头。

澄清一下：用户在 domainA.com 上。domainB.com 的 iframe 已打开，并尝试在 iframe 内对 domainB.com 上的用户进行身份验证。Set-Cookie 标头从 domainB.com iframe 内的服务器返回，带有所有必需的标头，但 Safari 不会在后续调用中将其发回。

一个旧的解决方法是从 iframe 提交表单，并在响应中设置 cookie。我猜他们喜欢用户点击某些东西来提交表单的事实。您必须轮询 cookie 以查看响应何时返回，因为表单提交没有回调，而在 HttpOnly cookie 的情况下，您不能，但是，嘿，它起作用了！直到没有。

然后，最近的解决方法是将用户重定向到全新窗口/选项卡中的 iframe 域，在那里设置一个随机 cookie，从那一刻起，该子域在 iframe 中被“信任”。同样，它需要单击才能打开新窗口/选项卡，甚至还有新选项卡打开的视觉指示。多安全，这样的标准。

现在，从 Safari 13 开始 - 没有更多的解决方法。没有更安全的 iframe cookie 设置

任何其他身份验证方案都不适合我们（例如 Auth-X 标头）。我们需要使用 HttpOnly 安全 cookie，因为我们不希望 javascript 客户端以任何方式访问该令牌。

需要明确的是，一切都在任何其他浏览器上运行良好。

相关的 WebKit Bugzilla

有没有人有什么建议？

编辑：

感谢@tomschmidt 的链接，这似乎是正确的方向。我尝试使用 Apple 的 Storage Access API，但不幸的是，虽然我确保在使用 API 初始化我的登录逻辑之前请求访问：

requestStorageAccess = async() => {
    return new Promise(resolve => {
      //@ts-ignore
      document.requestStorageAccess().then(
        function () {
          console.log('Storage access was granted');
          resolve(true);
        },
        function () {
          console.log('Storage access was denied');
          resolve(false);
        }
      );    
    });
  }


const storageAccessGranted = await requestStorageAccess();
console.log(storageAccessGranted) // prints 'true'
await login();

尽管如此，在 /login API 响应中收到的 cookie 不会在随后的 API 调用中发送:(

编辑 2（2021 年 5 月）：

Safari 14 增加了另一个突破性的变化：

https://webkit.org/blog/11545/updates-to-the-storage-access-api/

去苹果去！你让我们想起了 IE6。

Answer 1

我想我可能已经找到了解决方案：Apple的存储访问API： https://webkit.org/blog/8124/introducing-storage-access-api/