CORS 无法在 Chrome 上运行答案

【问题标题】：CORS not working on ChromeCORS 无法在 Chrome 上运行
【发布时间】：2011-03-09 08:18:42
【问题描述】：

我已经在服务器上设置了跨域资源共享（Jetty 使用 CrossOriginFilter），它在 IE8 和 Firefox 上完美运行。在 Chrome 上，它只是......没有。

  $.ajax({ url : crossOriginURL,
    type : "GET",
    error : function(req, message) {
        alert(message);
    },
    dataType :  "json" } );

错误函数被调用，并带有有用的消息“错误”。它似乎正在发出请求，但没有您期望的任何标头。如果 URL 来自同一来源，则可以正常工作。

【问题讨论】：

马伏里奥和CuSS是同一个人吗？
不！当然不是！哈哈。我今天早上也遇到了同样的问题。我迫切需要解决这个问题，所以不要重复这个问题，我已经对他的问题给予了赏金，但既然我现在已经解决了，我已经回答了。对不起我的英语不好。

标签： javascript jquery google-chrome cors

【解决方案1】：

我已经通过这种方式解决了我的问题：

将此添加到您的 PHP 代码中：

header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Credentials: true ");
header("Access-Control-Allow-Methods: OPTIONS, GET, POST");
header("Access-Control-Allow-Headers: Content-Type, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control");

或者将这些标题添加到您的响应中。

问题：浏览器在您的主要请求之前向服务器询问选项，以检查该站点是否可以选择允许与不同来源的通信，如果是，它们会执行您的 POST 或 GET 请求。

编辑：试试这个（没有你的黑客）看看你是否正在接收数据......

$.ajax({ url : crossOriginURL,
    type : "GET",
    error : function(req, message) {
        alert(message);
    },
    success : function(data) {
        alert(data);
    },
    dataType :  "text"} );

【讨论】：

实际上，最终对我有用的是 xhr.setRequestHeader('Content-Type', 'text/plain');
在这种情况下，您可以发布自己的答案并将其标记为正确答案吗？（我没有这个特殊的问题，但我确实希望保持未回答问题的列表干净）
我的答案适用于所有浏览器。您不需要请求自定义标头，因为谁限制页面是服务器和浏览器引擎...如果您收到空白响应，可能是 ajax 上的错误数据类型，这是因为您没有选择正确的数据类型。阅读 api.jquery.com/jQuery.ajax 中的 dataType。在 ajax 选项数组中放置 {dataType:"text"}
将内容类型设置为普通的解决方案对我不起作用（我收到一条错误消息，表明我无法在请求中设置）。而且我不是在编写自己的服务器服务，而是在使用另一个在线服务（推特）。是否有另一种仅使用 JavaScript 的解决方案？我还尝试使用与上述相同的技术（设置请求标头）将“来源”设置为特定的东西，但出现错误。我的代码在 Safari 中运行良好，但在 Chrome 中失败，尽管所有迹象都表明 Chrome 支持 CORS。
@CuSS 完美答案！我已经在服务器端包含了上述标题。仍然无法通过 AJAX 调用获取标头。然后我读到了你在答案中提到的'Problem: ' 部分，它帮助了我。我将header("Access-Control-Allow-Origin: *"); 添加为倒数第二个标题。当我更改订单（将其保留为第一个标题）时，它对我有用。我也只在选项中设置了type: 'GET'。保留dataType: 'jsonp' 不会为我返回标题，它只会返回响应/数据。这可能会帮助其他面临类似问题的人。再次感谢

【解决方案2】：

最后对我有用的是xhr.setRequestHeader('Content-Type', 'text/plain');

编辑：服务器需要添加Access-Control-Allow-Headers: Content-Type来避免这个问题。

十年后，我又回到了我自己的问题上。我不知道这是好事还是坏事。

【讨论】：

为了更全面地解释这一点，使用这样的“原始”数据可以避免在 CORS 中更常见的预检。由于没有飞行前，没有访问控制检查，从而避免了整个问题。 +1
@Richard 那只对了一半。它避免了预检，但即使是未预检的 CORS 请求也会产生错误（例如，如果没有匹配的 Access-Control-Allow-Origin: ... 响应标头。这样做的原因实际上很简单：text/plain 是极少数的内容类型之一在没有 explicit Access-Control-Allow-Headers: Content-Type 响应标头的情况下允许。json（或 application/json 需要显式标头允许。
@CBHacking -- 七年后，有人想出了正确的答案。七年后不知道是好是坏，我在两个小时内查看了网站。无论如何，你为什么不回答我可以接受？

【解决方案3】：

看起来原始发布者可能已经解决了他们的问题，但是对于与评论员 Elisabeth 有相同问题的任何人，我认为问题可能是 Chrome 拒绝为 CORS 请求设置 Origin 标头，如果您正在运行来自本地文件的请求。它甚至不会让您明确覆盖 Origin 标头。这会导致服务器看到“Origin：null”，在大多数情况下会导致 403。 Firefox 显然没有这样的限制，正如我在费尽心思之后发现的那样。

如果您在这种情况下绝对需要使用 Chrome，您可以通过在本地运行网络服务器并始终通过 http: 而不是通过 file: 访问您的文件来解决您的问题。

【讨论】：

在跨域安全关闭的情况下运行 Chrome 可以获得侵入性较小（尽管是临时）的解决方案：path/to/chrome --disable-web-security。警告：如果您继续使用不安全的 Chrome 浏览器进行常规浏览，则要么什么都不会发生，要么您的银行帐户将被黑客入侵，祝您好运。
这真的拯救了我的一天！一旦我将原始请求放在一个简单的 Web 服务器后面，一切都很好。

【解决方案4】：

当我更新 chrome 时，我遇到了问题，我已经解决了谷歌扩展“Access-Control-Allow-Credentials”新版本。如果是旧版本，则无需使用新的 Google Chrome 版本

https://chrome.google.com/webstore/detail/access-control-allow-cred/hmcjjmkppmkpobeokkhgkecjlaobjldi?hl=en

【讨论】：

【解决方案5】：

检查以确保您没有将服务器设置为允许凭据并将允许来源标头设置为 *。如下：

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

如果您的服务器正在为这些标头返回这些值，那么它将不起作用。如果将Access-Control-Allow-Credentials 设置为true，则不能使用* 作为Access-Control-Allow-Origin 标头的值。以下是 MDN 网络文档的标题摘录（https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin）：

For requests without credentials, the literal value "*" can be specified, as a wildcard; 
the value tells browsers to allow requesting code from any origin to access the resource. 
Attempting to use the wildcard with credentials will result in an error.

如果是上述情况，只需将Access-Control-Allow-Credentials 设置为false。

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: false

参考文献

【讨论】：

【解决方案6】：

我们实际上有两个域，一个是仪表板dashboard.app.com，另一个是公共网站app.com。请求来自公共网站，PHP 路由重定向到仪表板域，这就是我们收到错误的原因。解决方案是将所有请求保留在同一个域内，而不需要重定向。

【讨论】：

【解决方案7】：

在我的例子中，它是 localhost:8001（前端），它试图在 localhost:7001（作为节点服务器的 server.js 上）调用 API。即使我在 Chrome 上安装并打开了 CORS 插件，但 CORS 政策仍然拒绝将它们作为预检案例。

我花了半天多的时间才终于解决了这个问题。不管你信不信，这里是“愚蠢”的步骤：

我。关掉CORS插件，重新加载应用，此时你应该仍然会得到正确的错误。

二。重新打开，重新加载应用，如果API成功，则停止，无需继续进行iii。

三。但是，如果您仍然收到 CORS 拒绝，请卸载 Chrome 并安装最新的 Chrome。

四。在新的 Chrome 上，之前安装的 CORS 插件应该仍然存在，但处于关闭状态。

v.重新加载页面，您应该会在控制台上收到正确的 CORS 拒绝消息。

六。重新打开，重新加载页面，错误应该会消失。

如果上述步骤在您的情况下仍然不起作用，则没有进一步的想法。

我还在 server.js (Node) 上尝试了以下方法，但仍然无法正常工作，所以不用费心尝试：

var app = express();
var cors = require('cors'); // Already done “npm i cors --save-dev”
app.options('*', cors());

【讨论】：

【解决方案8】：

CORS 将在 chrome 中工作。只需使用 chrome 是安全模式，即使用禁用安全设置。谷歌一下，或者你甚至可以从命令行开始。

【讨论】：

这不是一个好的解决方案，因为 (a) 它本质上是 un 安全的，(b) 它要求用户停止 Chrome，然后重新启动它，然后我的网站才会工作，并且 (c) 我需要 三年前的解决方案！