为什么我的重定向 CORS 请求失败？答案

【问题标题】：Why does my redirected CORS request fail?为什么我的重定向 CORS 请求失败？
【发布时间】：2014-10-19 09:16:10
【问题描述】：

我的问题是我的应用程序在 localhost:8080 上运行的 angularjs $http 调用

var url "https://api.acme.com/RX/v1/user";
$http.get(url).success(function (data) {
    alert('yay');
$scope.user = data;
});

第一个请求成功，Chrome 记录了以下响应：

Status Code:302 Found
Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:http://localhost:8080
Location:https://login.acme.com/cas/login?service=https%3A%2F%2Fapi.acme.com%2FRX%2Fv1%2Fuser

这会导致浏览器向重定向位置发出第二个 GET 请求：

https://login.acme.com/cas/login?service=https%3A%2F%2Fapi.acme.com%2FRX%2Fv1%2Fuser

第二个请求失败并在 Chrome 中报告以下错误：

XMLHttpRequest cannot load https://login.acme.com/cas/login?service=https%3A%2F%2Fapi.acme.com%2FRX%2Fv1%2Fuser. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

所以我有一个从源到 url 的 CORS 请求，该请求允许将请求重定向到另一个也配置为允许请求的 url。但是重定向请求失败。我应该期望这行得通吗？

注意，api.acme.com 和 login.acme.com 都配置为允许所有来源使用

Access-Control-Allow-Origin: *

【问题讨论】：

标签： angularjs cors

【解决方案1】：

请参阅本节 (7.1.7) 的第 6 步：http://www.w3.org/TR/cors/#redirect-steps

更多讨论可以在这里找到：https://code.google.com/p/chromium/issues/detail?id=154967

不幸的是，传输字符串“null”的约定使它看起来像是一个错误；我自己也是这么想的，直到我找到了这个:)

【讨论】：

我想知道源源切换为null的原因是什么：“如果请求URL源与原始URL源不同源，将源源设置为全局唯一标识符（传输时变为“null”）。”
可能是来自“The Web Origin Concept”tools.ietf.org/html/rfc6454#section-7.3 的评论： > 每当用户代理从“隐私敏感”上下文发出 HTTP 请求时，用户代理必须发送该值Origin 标头字段中的“null”。”
@DaleOgilvie 也许，就我而言，来自blah.net 的用户代理首先请求a.example.com（Origin 标头设置为“blah.net”），然后重定向到b.example.com（使用Origin标题“空”）。在b.example.com 上添加null 到Access-Control-Allow-Origin 有效，但不安全:(

【解决方案2】：

这个问题是由浏览器在 XHR 请求返回 302 时将 Origin 设置为 null 引起的。顺便说一句，这对我来说似乎很奇怪，因为使用原始 Origin 而不是 null 来制作 302 肯定会更有意义。

当 Origin null 到达我们的服务器时，那里的 apache tomcat CORS 实现（http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter，tomcat 7.0.52）不会返回 Access-Control-Allow-Origin 标头，即使服务器配置为允许 ALL起源。 注意：此行为现已在当前版本的 Tomcat 7 中得到修复。

解决方案是在服务器上使用不同的 CORS 实现 (http://software.dzhuvinov.com/cors-filter.html)。此过滤器返回 Access-Control-Allow-Origin: null 并且 302 XHR 成功。

虽然我找到了解决方案，但我仍然不确定两件事：

为什么当 XHR 导致重定向时浏览器会发送 Origin null
tomcat 过滤器或 dzhuvinov 软件过滤器是否正确响应 Origin null。

【讨论】：

我也对此感兴趣以及客户端的解决方案。
但是不返回 Access-Control-Allow-Origin: null 会使您的服务易受攻击吗？任何人都可以在客户端将其原点设置为 null
该服务是使用另一种机制授权的，它允许任何给定附加到请求的正确令牌的来源。
规格说：If a cross-origin resource redirects to another resource at a new origin, the browser will set the value of the Origin header to null after redirecting. This prevents additional confused deputy attacks, but a cost of making it difficult to transparently move CORS resources that support (cookie-based) credentials and simple requests across domains with 3xx status codes one can with non-CORS resourcesw3c.github.io/webappsec-cors-for-developers
你不应该允许来源：空。 W3C has a whole section about this 但归根结底，它几乎完全违背了 Allow-Origin 的初衷。

【解决方案3】：

如果您使用 LoginRequiredMiddleware，请务必在 settings.py 中将 url 添加到 LOGIN_EXEMPT_URLS。

【讨论】：