显然,我完全误解了它的语义。我想到了这样的事情:

客户端从下载JavaScript代码MyCode.jshttp://siteA-原产地。MyCode.js的响应标头包含Access Control Allow Origin:http://siteB,我认为这意味着允许MyCode.js对站点B进行跨源引用。客户端触发MyCode.js的一些功能,进而向http://siteB,这应该可以,尽管是跨源请求。

嗯,我错了。它根本不是这样工作的。所以,我已经阅读了跨源资源共享,并尝试阅读w3c推荐中的跨源资源分享。

有一点是肯定的——我仍然不明白我应该如何使用这个标题。

我完全控制站点A和站点B。如何使从站点A下载的JavaScript代码使用此标头访问站点B上的资源?

备注:我不想使用JSONP。


当前回答

如果您正在使用PHP,请尝试在PHP文件的开头添加以下代码:

如果您使用的是localhost,请尝试以下操作:

header("Access-Control-Allow-Origin: *");

如果您正在使用外部域(如服务器),请尝试以下操作:

header("Access-Control-Allow-Origin: http://www.website.com");

其他回答

如果您只想测试浏览器阻止您请求的跨域应用程序,那么您可以在不安全模式下打开浏览器并测试应用程序,而不更改代码,也不使代码不安全。

在macOS中,您可以从终端行执行此操作:

open -a Google\ Chrome --args --disable-web-security --user-data-dir

我使用Express.js 4、Node.js 7.4和Angular,但遇到了同样的问题。这帮助了我:

a) 服务器端:在app.js文件中,我向所有响应添加头,比如:

app.use(function(req, res, next) {
    res.header('Access-Control-Allow-Origin', req.headers.origin);
    res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
    next();
});

这必须在所有路线之前。

我看到很多人添加了这个标题:

res.header("Access-Control-Allow-Headers","*");
res.header('Access-Control-Allow-Credentials', true);
res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');

但我不需要,

b) 客户端:通过Ajax发送时,需要添加“withCredentials:true”,如:

$http({
     method: 'POST',
     url: 'url',
     withCredentials: true,
     data : {}
   }).then(function(response){
       // Code
   }, function (response) {
       // Code
});

只需将以下代码粘贴到web.config文件中。

注意,您必须在<system.webServer>标记下粘贴以下代码

<httpProtocol>
  <customHeaders>
   <add name="Access-Control-Allow-Origin" value="*" />
   <add name="Access-Control-Allow-Headers" value="Content-Type" />
   <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
  </customHeaders>
</httpProtocol>

如果您正在使用PHP,请尝试在PHP文件的开头添加以下代码:

如果您使用的是localhost,请尝试以下操作:

header("Access-Control-Allow-Origin: *");

如果您正在使用外部域(如服务器),请尝试以下操作:

header("Access-Control-Allow-Origin: http://www.website.com");

每当我开始思考CORS时,我对哪个站点托管标头的直觉是错误的,正如您在问题中所描述的那样。对我来说,思考同源政策的目的是有帮助的。

同源策略的目的是保护您免受siteA.com上的恶意JavaScript访问您选择仅与siteB.com共享的私人信息。如果没有同源策略,siteA.com作者编写的JavaScript可能会让您的浏览器使用您的siteB.com身份验证cookie向siteB.com发出请求。这样,siteA.com可能会窃取您与siteB.com共享的秘密信息。

有时您需要跨域工作,这就是CORS的作用所在。CORS放宽了siteB.com的同源策略,使用Access Control Allow origin标头列出其他受信任运行可与siteB.com交互的JavaScript的域(siteA.com)。

要了解哪个域应该为CORS标头提供服务,请考虑这一点。您访问malious.com,其中包含一些试图向mybank.com发出跨域请求的JavaScript。应该由mybank.com而不是malious.com来决定它是否设置CORS标头,以放宽同源策略,从而允许maliouss.com中的JavaScript与之交互。如果malious.com可以设置自己的CORS标头,允许自己的JavaScript访问mybank.com,这将完全取消同源策略。

我认为我直觉不好的原因是我在开发网站时的观点。这是我的网站,有我所有的JavaScript。因此,它没有做任何恶意的事情,应该由我来指定我的JavaScript可以与哪些其他站点交互。事实上,我应该思考:哪些其他网站的JavaScript正在尝试与我的网站交互,我应该使用CORS来允许它们?