CORS 问题与 window.open() 和 OAuth2

Question

我正在运行一个使用SharedArrayBuffer (ffmpeg wasm) 的站点，它严格要求 CORS（和/或站点隔离）和Discord oauth2 工作流。 从今年早些时候开始就没有查看该网站后，我发现它不再适用于最新版本的 Chrome。 最终查明Discord oauth流量的问题与CORS有关。

使用window.open()时，（同源）CORS 将阻止您的网站与所述新的 window 交互，如果它在另一个域上（如果我理解正确的话）。 检查 window promise 返回 window 已经关闭（ window.closed == true ），甚至认为它没有。

我注册了Origin Trials （希望same-origin-allow-popups能尽快生效）。 这确实修复了流程的 Discord 部分。 检查window promise返回正常。 但是，一旦我被重定向回我自己的网站，它再次声称 window 已关闭（在我获得 oauth 代码之前）。

为什么 CORS 会阻止我阅读我自己的网站？ 是不是因为之前的document.domain设置为discord.com ？

有谁知道解决此类问题的任何好方法？ CORS 错误很常见，但没有CORS 错误，只有window.closed == true 。

Answer 1

简短回答：检查您的请求和响应中的Referer （拼写错误是故意的）header。 新的基于 Chromium 的浏览器（Chrome、Chromium 和 MS Edge）将返回 URL 到原点，因为它有严格的新默认策略。

您可以通过多种方式设置适当的策略。 我不建议使用笼统的“无推荐人”，这可能有风险。 “no-referrer-when-downgrade”可能是一个更安全的选择。 一旦以编程方式或通过配置您的应用程序设置此策略，浏览器将检查并适当地发送重定向。

详细阅读：简而言之，chromium 增强了安全性，因此除非在请求 header 中定义了 referrer 策略，否则 chromium 会将 go 重定向到原始来源。

我遇到了一个类似的问题，即 oauth 的重定向并返回到应用程序会在 IE 中按预期工作，但它不会在基于 Chromium 的浏览器（Chrome、Chromium 和 MS Edge）中工作。 从 oauth 提供商成功重定向后，重定向将 go 到原始主机。

这是我的场景

www.hostA.com (Origin)
www.hostB.com/search/product/123 (CORS destination)
www.oauth-provider.com (OAuth Provider)

hostA 和 hostB 都在 oauth 认证之后。 因此，当 hostA 打开对 hostB 的请求时，浏览器正在设置默认策略“strict-origin”，因此 referrer 被添加到“hostA”的 header 并将其重定向到 OAuth，以便用户可以提供凭据和多因素身份验证等.

当 auth-provider 收到请求以及策略 header 时，它会进行身份验证，并在身份验证成功后将其与原始标头一起重定向回浏览器。 现在浏览器查看引荐来源网址，因此 URL 变为www.hostA.com/search/product/123而不是www.hostB.com/search/product/123 ，有效地回落到原始请求，同时保持 URL 的 rest 完好无损.

解决方案：在原始应用程序上设置正确的引用策略可以解决此问题。 在我的例子中，它是一个 JavaScript Angular 并且在 window.open 中指定引用策略作为参数起作用。 但是，可以通过多种方式定义/修改策略，例如安全过滤器、拦截器代理等，具体取决于最安全的选项。

例子：

• 对于 JavaScript： https://developer.mozilla.org/en-US/docs/Web/API/Window/open#noreferrer
• Java Spring： https://docs.spring.io/spring-security/site/docs/5.2.0.RELEASE/reference/html/default-security-headers-2.html#Referrer%20Policy

一些额外的阅读帮助我找到了这个棘手的问题——

• https://developer.chrome.com/blog/referrer-policy-new-chrome-default/
• https://www.w3.org/TR/referrer-policy/#referrer-policy-no-referrer
• https://privacyinternational.org/guide-step/4149/change-http-referer-settings-chrome