CORS 重定向意外工作答案

【问题标题】：CORS redirect works unexpectedlyCORS 重定向意外工作
【发布时间】：2016-11-02 22:14:02
【问题描述】：

根据 CORS 规范（7.1.7 - 重定向步骤（用于简单跨域请求））：

如果请求 URL 来源与原始 URL 来源不同，请将来源来源设置为全局唯一标识符（传输时变为“null”）。

我有一个场景，来自 a.blah.com 的 javascript 通过将浏览器发送到 b.blah.com 来发出 CORS 请求（即存在 Origin 请求标头），b.blah.com 以 302 和 location = c.blah.com 响应。如果我正确阅读规范，这应该会导致对 c.blah.com 的请求包含 Origin 标头 =“null”。相反，Origin 标头不存在，因此对 c.blah.com 的请求不被视为 CORS 请求。

上述行为在 Chrome 54 中出现。我尚未在其他浏览器中确认确切的请求内容，但我已检查我的特定应用程序流在 Chrome 54、Firefox 37 和 IE 11 浏览器中是否有效，这意味着它们永远不会请参阅 Origin 标头设置为“null”（如果接收到 Origin =“null”，我的服务将大声失败请求）。

这一切都让我担心，因为当我的应用程序运行时，它实际上不应该运行，我不想忽略这个事实。我误解了规范吗？我错过的规范行为是否有任何警告？

所有流量都是 HTTPS，不在 CORS 响应标头中返回 *（通配符），根据需要设置 with-credentials 标志/标头，没有使用代理，所有参与者都在不同的机器上，所以不应该是本地主机陷阱...

谢谢。

【问题讨论】：

这些 HTTP 请求究竟是如何产生的？
对 b.blah.com 的请求是 js 发布的表单（不是 xhr）。我设置了一个测试，其中对 b.blah.com 的请求是 xhr，这确实导致对 c.blah.com 的请求出现 Origin = "null"。经过一番挖掘，我似乎需要更好地研究何时执行同源策略的细微差别。

标签： javascript redirect https cors

【解决方案1】：

在我的原始配置中，对 b.blah.com 的请求是由 js（不是 xhr）发布的表单。经过一番挖掘，似乎由于请求是由 js 触发的，因此需要在对 b.blah.com 的请求上使用 Origin 标头，但生成的对 c.blah.com 的重定向是由浏览器处理的，没有任何脚本/ xhr 干预，因此重定向没有用 Origin 标头装饰。

我设置了一个测试，其中对 b.blah.com 的请求是 xhr，这确实导致重定向到 c.blah.com 时出现 Origin = "null"。

我想我需要更好地研究何时执行同源政策的细微差别。

谢谢。

【讨论】：