带有 Preflight 和重定向的 CORS 请求：不允许。解决方法？

Question

我正在设计一个 API，它允许用户进行身份验证（使用令牌）并包含同一域内的重定向。现在，对于返回 303 的端点的未经身份验证的请求，

GET /documents/123  --> 303 redirect to `/documents/abc`
GET /documents/abc  --> 200

一切都很顺利。

让我们向发送Authorization 标头的同一端点发出经过身份验证的请求。这使得请求成为 preflighted request 并且浏览器执行预检 OPTIONS 请求，即

OPTIONS /documents/123   --> 204 (everything okay, please proceed)
GET /documents/123       --> 303 redirect to `/documents/abc`

此时，浏览器不会在/documents/abc 处找到实际资源，而不是GETting

XMLHttpRequest cannot load http://localhost:8000/people/username/nschloe. 
The request was redirected to 'http://localhost:8000/people/YDHa-B2FhMie', 
which is disallowed for cross-origin requests that require preflight.

此行为符合the standard：

7.1.5 带预检的跨域请求

如果响应的 HTTP 状态码不在 2xx 范围内

应用网络错误步骤。

这似乎意味着一个不能对经过身份验证的资源进行重定向，即使重定向位于同一个域 (localhost)。

这真的是真的吗？有通用的解决方法吗？

Answer 1

在成功的 CORS 预检后，原始标准确实排除了重定向。 Quoting § 7.1.5.3:

这是实际的请求。提出请求时应用提出请求的步骤并遵守以下请求规则。

• 如果响应的 HTTP 状态代码为 301、302、303、307 或 308 应用缓存和网络错误步骤。

由于您的努力（谢谢！），2016 年 8 月 4 日，标准是 updated，以允许在成功的 CORS 预检检查后重定向。

在浏览器赶上之前，唯一可行的选择似乎是以下一种或多种：

1. 仅为simple requests 发出重定向。
2. 发出305 redirect，在Location 标头中使用您自己的URL 作为“代理”。为有限的浏览器支持做好准备，因为 305 已被弃用。
3. 做一个虚假的“重定向”：

• 使用meta refresh 和/或Javascript Location 更改返回HTML。
• 返回具有视口填充iframe 的 HTML，并将重定向目标作为 iframe 的源。
• 显示用户必须单击才能访问内容的链接。