16

背景

（如果你熟悉CORS，你可以跳到最后的问题）

CORS [1] 是一种允许浏览器允许访问来自不同域的资源的解决方案。例如使用 AJAX 的 REST 数据后端。

在 Internet 上很好地观察到，当此类资源需要时，Chrome（和 Webkit 朋友）不会处理 HTTP 身份验证提示。例如 [2] （这是为了防止浏览器显示身份验证登录对话框，例如，当图像标签加载失败并出现 401 并需要凭据时，Web-Mail 登录页面。用户可能被欺骗输入他们的网络邮件凭据）

Chrome 在这种情况下的行为是放弃响应，几乎是默默地取消请求。

实际上，只有在出现 200 时，Chrome 才会让响应正常通过；吞下任何其他状态代码并中止 AJAX 调用。

如果使用 jQuery 执行 Ajax 请求，并且远程站点以 HTTP 401 状态代码响应，则请求被取消并且 ajax 完成并出现错误，但缺少 401 代码。好像连接死了或等效的低层问题。

我见过的唯一一个特别提到 CORS 警告的网站是 [1]

当出现错误时，浏览器并不能很好地报告问题所在。例如，Firefox 报告所有错误的状态为 0 和空的 statusText。浏览器还会向控制台日志报告错误消息，但无法从 JavaScript 访问此消息。在处理 onerror 时，您会知道发生了错误，但仅此而已。

您可以通过使用 chrome 启动标志来禁用此安全性 - 只是为了测试后端是否“正常”运行，并且一个理智没有因丢失正确的状态代码而受到过度影响。见[2]

问题

如果后端和前端客户端代码应该使用 401 作为其身份验证过程的一部分怎么办？- 任何失败都只是被分解为一个“错误”输出。

例如：在发出身份验证请求时 - 例如 2-legged OAuth 令牌请求 - 针对 RESTful 后端 - 使用正确的状态代码 - 客户端不知道是否：

  • 401用户未通过身份验证。
  • ---连接失败。
  • 400有一个错误的请求。
  • 500服务器有问题。
  • 207成功后没有内容。

我们的后端写得很RESTful，遵循当时被认为具有成本效益的尽可能多的最佳实践；其中之一是依赖正确的 HTTP 状态代码。我们使用的 Java REST 客户端运行良好。

现在我已经开始创建一个 Javascript 客户端，用于嵌入网页 - 特别是使用 CORS，我们在 Chrome 等中遇到了问题。（注意 Firefox似乎很好，我们目前一般不关心 IE。）

问题

人们为解决这些问题做了哪些工作？
有什么办法可以让 CORS 更适合受信任的后端？

链接

  1. CORS 教程：http ://www.html5rocks.com/en/tutorials/cors/
  2. Chrome 不允许 401 触发的资源身份验证提示：http ://code.google.com/p/chromium/issues/detail?id=81251
  3. --disable-web-security for Chrome：在 Chrome 中禁用同源策略
4

3 回答 3

6

刚碰到这个问题。为 401 响应设置 HTTP 标头对我有用。如果没有一些自定义，我正在使用的库无法正确执行此操作。例如：

  self.headers["Access-Control-Max-Age"] = '1728000'
  self.headers["Access-Control-Allow-Origin"] = "http://localhost:3001"
  self.headers["Access-Control-Allow-Methods"] = "ANY"
  self.headers["Access-Control-Allow-Credentials"] = 'true'
于 2013-07-17T13:22:40.273 回答
1

我今天花了几个小时寻找这个问题的答案，同时在 Chrome 上开发一个网络应用程序。其他一些人已经对这种情况进行了相当详细的分析。

有两个潜在的问题：

  1. 可能是 Chrome 正在进行预检，并得到了非 200 或非 CORS 响应作为响应

  2. 由于某种原因，我的非 200（错误）状态代码没有附加标题。正如我在这篇文章中发现的那样，第二个原因就是问题所在。本质上，NGINX 默认只在成功响应上添加标头。要通过 CORS 获得我的错误响应，只需更改

add_header 'Access-Control-Allow-Origin' '*';

至

add_header 'Access-Control-Allow-Origin' '*' always;

如文章所述，您可能还必须添加always到'Access-Control-Allow-Credentials'和'Access-Control-Allow-Headers'。这样做之后，所有错误代码也都通过了，没有 CORS 问题。您用于 API 服务的程序可能也是如此。希望这有助于并节省一些时间！

于 2020-09-08T07:13:19.660 回答
-3

现在经过多次摆弄，我已经设法让它工作了。脸红

似乎有很多伏都教构成了确保 CORS 可以在每个浏览器中工作的确切场景，但是已经追溯了许多问题，例如：

  • Nginx 默认只在其反向代理中使用 HTTP/1.0
  • Tomcat 默默地忽略了具有相同密钥的重复 init-param 声明，但码头将它们组合在一起（因此 CORS 过滤器在服务器中关闭但在 dev-laptop 中打开），并且 nginx 覆盖了一些标头。

偶然发现似乎完全不行，我最终编写了一个 CORS 4xx->200 包装器作为 jquery 插件，试图解决这个问题。调试该插件使我最终解决了问题。

于 2012-10-01T23:19:07.213 回答