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

客户端从下载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。


当前回答

Nginx和Apache

作为apsiller答案的补充,我想添加一个wiki图表,显示请求是否简单(OPTIONS航班前请求是否发送)

对于一个简单的请求(例如,热链接图像),您不需要更改服务器配置文件,但您可以像Melvin Guerrero在回答中提到的那样在应用程序(托管在服务器上,例如,在PHP中)中添加头标,但请记住:如果您在服务器(配置)中添加完整的CORS头标,同时在应用程序中允许简单的CORS(例如,PHP),这根本行不通。

下面是两种常用服务器的配置:

打开Nginx上的CORS(Nginx.conf文件)位置~^/index\.php(/|$){...add_header'访问控制允许来源'“$http_Origin”始终;#如果您将“$http_origin”更改为“*”,您将得到相同的结果-允许所有域使用CORS(但最好将其更改为您的特定域)add_header“访问控制允许凭据”“始终为true”;if($request_method=OPTIONS){add_header'访问控制允许来源'“$http_Origin”;#请勿移除该行(用上面的外部“if”加倍)add_header'访问控制允许凭据''true';add_header'访问控制最大年龄'1728000;#缓存20天的飞行前值add_header'访问控制允许方法''GET,POST,OPTIONS';#任意方法add_header'访问控制允许标头''我的第一个标头,我的第二个标头,授权,内容类型,接受,来源';#任意标头add_header“内容长度”0;add_header“内容类型”“text/plain charset=UTF-8”;返回204;}}在Apache上打开CORS(.htaccess文件)# ------------------------------------------------------------------------------#|跨域Ajax请求|# ------------------------------------------------------------------------------#启用跨源Ajax请求。# http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity# http://enable-cors.org/#将下面的*(允许任何域)更改为您的域标题集访问控制允许来源“*”标头始终设置访问控制允许方法“POST、GET、OPTIONS、DELETE、PUT”标头始终设置访问控制允许标头“My First Header,My Second Header,Authorization,content type,csrf token”标头始终将访问控制允许凭据设置为“true”

其他回答

每当我开始思考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来允许它们?

访问控制允许源是CORS(跨源资源共享)标头。

当站点A尝试从站点B获取内容时,站点B可以发送一个访问控制允许源站响应标头,告诉浏览器此页面的内容可由特定源站访问。(源站是一个域,加上一个方案和端口号。)默认情况下,站点B的页面不可由任何其他源站访问;使用Access Control Allow Origin(访问控制允许来源)标头为特定请求来源的跨来源访问打开了一扇门。

对于站点B希望站点A访问的每个资源/页面,站点B应为其页面提供响应标题:

Access-Control-Allow-Origin: http://siteA.com

现代浏览器不会完全阻止跨域请求。如果站点A从站点B请求页面,浏览器将在网络级别实际获取请求的页面,并检查响应标头是否将站点A列为允许的请求者域。如果站点B未指示站点A被允许访问此页面,浏览器将触发XMLHttpRequest的错误事件,并拒绝向请求的JavaScript代码提供响应数据。

非简单请求

在网络层面发生的事情可能比上面解释的稍微复杂一些。如果请求是“非简单”请求,则浏览器首先发送一个无数据的“预检”OPTIONS请求,以验证服务器是否接受该请求。在以下情况之一(或两者)时,请求是非简单的:

使用GET或POST以外的HTTP动词(例如PUT、DELETE)使用非简单请求头;唯一简单的请求头是:接受接受语言内容语言内容类型(仅当其值为application/x-wwww-form-urlencoded、multipart/form-data或text/plain时才简单)

如果服务器使用与非简单谓词和/或非简单标头匹配的适当响应标头(非简单标头的访问控制允许标头,非简单谓词的访问控制方法)响应OPTIONS预检,则浏览器发送实际请求。

假设站点A想要发送一个对/somePage的PUT请求,其中一个非简单的Content-Type值为application/json,浏览器将首先发送一个预检请求:

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

注意,访问控制请求方法和访问控制请求头由浏览器自动添加;您不需要添加它们。此OPTIONS预检获得成功的响应标头:

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

在发送实际请求时(飞行前完成后),行为与处理简单请求的方式相同。换言之,预飞成功的非简单请求被视为简单请求(即,服务器仍然必须再次发送访问控制允许源以获得实际响应)。

浏览器发送实际请求:

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

服务器会发回一个“访问控制允许源”,就像对一个简单的请求一样:

Access-Control-Allow-Origin: http://siteA.com

有关非简单请求的更多信息,请参阅了解CORS上的XMLHttpRequest。

对于跨源共享,请设置标题:“Access Control Allow origin”:“*”;

Php:header(“访问控制-允许原始”:“*”);

节点:app.use('Access-Control-Allow-Origin':'*');

这将允许共享不同域的内容。

我无法在后端服务器上配置它,但通过浏览器中的这些扩展,它对我很有用:

对于Firefox:

CORS无处不在

对于Google Chrome:

允许CORS:访问控制允许源

注意:CORS适用于此配置:

注:仅用于测试的临时解决方案

对于那些无法控制“选项405方法不允许”的后端的人,这里有一个解决方案,用于“颜色”浏览器。

在命令行中执行:

“C:\Program Files(x86)\Google\Chrome\Application\Chrome.exe”--禁用web安全--用户数据dir=“path_to_file”

例子:

“C:\Program Files(x86)\Google\Chrome\Application\Chrome.exe”--禁用web安全--用户数据dir=“C:\Users\vital\AppData\Local\Google\Cherme\user data\Profile 2”