浏览器和服务器实现跨域(CORS)判定的原理

前端对Cross-Origin Resource Sharing 问题(CORS,中文又称'跨域')应该很熟悉了。众所周知出于安全的考虑,浏览器有个 同源策略,对于不同源的站点之间的相互请求会做限制( 跨域限制是浏览器行为,不是服务器行为。)。不过下午想到了一个略无趣的问题:浏览器和服务器到底是如何判定有没有跨域呢?本文主要分两个部分,一是对这个问题的总结,二是nginx下如何配置服务器允许跨域。
<!-- more -->

同源策略

同源指的是域名(或IP),协议,端口都相同,不同源的客户端脚本(javascript、ActionScript)在没明确授权的情况下,不能读写对方的资源。

同源的判定:
http://www.example.com/dir/page.html为例,以下表格指出了不同形式的链接是否与其同源:(原因里未申明不同的属性即说明其与例子里的原链接对应的属性相同)

链接结果原因
http:// www.example.com /dir/page2.html同协议同域名同端口
http:// www.example.com /dir2/other.html同协议同域名同端口
http://user:pwd@ www.example.com/dir2/other.html同协议同域名同端口
http://www.example.com: 81/dir/other.html端口不同
https://www.example.com/dir/other.html协议不同端口不同
http:// en.example.com/dir/other.html域名不同
http:// example.com/dir/other.html域名不同(要求精确匹配)
http:// v2.www.example.com/dir/other.html域名不同(要求精确匹配)
http://www.example.com: 80/dir/other.html不确定取决于浏览器的实现方式

是否允许跨域的判定

前文提到了同源策略的判定,然而同源策略在加强了安全的同时,对开发却是极大的不便利。因此开发者们又发明了很多办法来允许数据的跨域传输(常见的办法有JSONPCORS)。当域名不同源的时候,由于跨域实现的存在,浏览器不能直接根据域名来判定跨域限制。那么浏览器具体又是如何实现判定的呢?看下面的例子。

环境说明

  1. 参与实验的前端域名三个有:http://www.zhihu.comhttp://segmentfault.com
    http://localhost

  2. 请求的服务器端地址为http://localhost/city.json,服务器解析引擎使用的nginx,且服务器只配置了允许来自http://segmentfault.com的跨域请求

  3. 检测方法:在各个域名下利用chrome浏览器的console界面模拟发送ajax请求,代码如下:

    var xhr = new XMLHttpRequest();
    xhr.open('GET', 'http://localhost/city.json',true);
    xhr.send();

实验过程

  1. http://localhost域名下,请求成功。

    服务器回应的http文件头如下:
    HTTP/1.1 200 OK
    Server: nginx/1.6.2
    Date: Sun, 05 Jul 2015 17:44:06 GMT
    Content-Type: application/octet-stream
    Content-Length: 2084
    Last-Modified: Sat, 18 Apr 2015 06:20:12 GMT
    Connection: keep-alive
    ETag: "5531f79c-824"
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Methods: GET, POST, OPTIONS
    Accept-Ranges: bytes
  2. http://segmentfault.com域名下,请求成功

    服务器回应的http文件头如下:
    HTTP/1.1 200 OK
    Server: nginx/1.6.2
    Date: Sun, 05 Jul 2015 18:17:27 GMT
    Content-Type: application/octet-stream
    Content-Length: 2084
    Last-Modified: Sat, 18 Apr 2015 06:20:12 GMT
    Connection: keep-alive
    ETag: "5531f79c-824"
    **Access-Control-Allow-origin: http://segmentfault.com**
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Methods: GET, POST, OPTIONS
    Accept-Ranges: bytes
  3. http://www.zhihu.com下,请求失败
    虽然都是失败,但是返回的HTTP文件头内容会视服务器是否有配置跨域请求而发生变化

服务器允许跨域请求

(仅允许来自http://segmentfault.com的跨域请求)
console.log窗口提示:

XMLHttpRequest cannot load http://localhost/city.json. The 'Access-Control-Allow-Origin' header has a value 'http://segmentfault.com' that is not equal to the supplied origin. Origin 'http://www.zhihu.com' is therefore notallowed access.

服务器回应的http文件头如下:

    HTTP/1.1 200 OK
    Server: nginx/1.6.2
    Date: Sun, 05 Jul 2015 17:59:25 GMT
    Content-Type: application/octet-stream
    Content-Length: 2084
    Last-Modified: Sat, 18 Apr 2015 06:20:12 GMT
    Connection: keep-alive
    ETag: "5531f79c-824"
    Access-Control-Allow-origin: http://segmentfault.com
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Methods: GET, POST, OPTIONS
    Accept-Ranges: bytes
服务器不允许任何跨域请求

console.log窗口提示:

XMLHttpRequest cannot load http://localhost/city.json. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.zhihu.com' is therefore not allowed access.

服务器回应的http文件头如下:

HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Sun, 05 Jul 2015 17:51:29 GMT
Content-Type: application/octet-stream
Content-Length: 2084
Last-Modified: Sat, 18 Apr 2015 06:20:12 GMT
Connection: keep-alive
ETag: "5531f79c-824"
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, OPTIONS
Accept-Ranges: bytes

跨域的判定流程

zhihu页面的两次浏览器报错以及segmentfault的成功返回值来看,可以很容易得出浏览器和服务器的合作判定步骤如下:

  1. 浏览器先根据同源策略对前端页面和后台交互地址做匹配,若同源,则直接发送数据请求;若不同源,则发送跨域请求。

  2. 服务器解析程序收到浏览器跨域请求后,根据自身配置返回对应文件头。若未配置过任何允许跨域,则文件头里不包含Access-Control-Allow-origin字段,若配置过域名,则返回Access-Control-Allow-origin对应配置规则里的域名的方式

  3. 浏览器根据接受到的http文件头里的Access-Control-Allow-origin字段做匹配,若无该字段,说明不允许跨域;若有该字段,则对字段内容和当前域名做比对,如果同源,则说明可以跨域,浏览器发送该请求;若不同源,则说明该域名不可跨域,不发送请求

(但是不能仅仅根据服务器返回的文件头里是否包含Access-Control-Allow-origin来判断其是否允许跨域,因为服务器端配置多域名跨域的时候,也会出现不能跨域的域名返回包里没有Access-Control-Allow-origin字段的情况。下文配置说明里会讲。)

配置服务器实现跨域传输

前面讲到了同源策略的基本判定,以及浏览器实现跨域判断的方式,那么,如何在服务器端做配置来允许跨域传输呢?下文将以Nginx为例,讲一下三种情况下的配置。

配置项解析

CORS常用的配置项有以下几个:

  • Access-Control-Allow-Origin(必含) – 允许的域名,只能填通配符或者单域名

  • Access-Control-Allow-Methods(必含) – 这允许跨域请求的http方法(常见有POSTGETOPTIONS

  • Access-Control-Allow-Headers(当预请求中包含Access-Control-Request-Headers时必须包含) – 这是对预请求当中Access-Control-Request-Headers的回复,和上面一样是以逗号分隔的列表,可以返回所有支持的头部。

  • Access-Control-Allow-Credentials(可选) – 该项标志着请求当中是否包含cookies信息,只有一个可选值:true(必为小写)。如果不包含cookies,请略去该项,而不是填写false。这一项与XmlHttpRequest2对象当中的withCredentials属性应保持一致,即withCredentials为true时该项也为true;withCredentials为false时,省略该项不写。反之则导致请求失败。

  • Access-Control-Max-Age(可选) – 以秒为单位的缓存时间。预请求的的发送并非免费午餐,允许时应当尽可能缓存。

具体配置举例

全域名或者单域名允许跨域

这个最省心
打开Nginx的配置文件(默认为nginx.conf)。找到对应域名设置的local配置部分。
添加以下内容:

add_header 'Access-Control-Allow-origin' 'http://www.example.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

添加的域名必须带http://协议头(否则服务器无法区分是http还是https),如果接受所有域名的跨域请求,则可以用*(安全性有问题,不推荐)

添加多域名跨域配置

如果允许跨域的域名有多个但出于安全问题又不想配置全域名通配的时候,就可以用到nginx里的if判断了。
添加如下内容:

if ($http_origin = 'http://segmentfault.com' ) {  
 add_header 'Access-Control-Allow-Origin' "$http_origin";
 }
if ($http_origin = 'http://localhost:4000' ) {  
 add_header 'Access-Control-Allow-Origin' "$http_origin";
 }
 add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
  • 如果对正则比较熟悉的,可以直接用正则来匹配条件判断,不需要用if这么麻烦的方式。

  • 'Access-Control-Allow-Methods' 允许多参数,'Access-Control-Allow-origin'不允许多参数,所以只能是条件语句判断要不要加这个。这也是我前面提到的为什么即使HTTP文件头返回值里没有'Access-Control-Allow-origin',也不能说明它就是不允许跨域的。

  • nginx配置文件的http配置部分不能用if条件语句,所以多域名的时候必须加在local部分内。另外加在local内的只对对应的服务器域名做跨域请求的配置,加在http里会让跑在该nginx下的所有网站都统一采取这种配置。

  • Access-Control-Allow-Origin也可以改成全小写的形式,不影响结果.(access-control-allow-origin也可以)

  • 17
    点赞
  • 62
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
CORS资源共享)是一种浏览器机制,用于解决在同源策略限制下的访问问题。同源策略是浏览器的一种安全策略,它要求网页只能从同一个名、协议和端口加载资源。 CORS工作原理如下: 1. 客户端发起请求:当客户端发送一个请求时,浏览器会在请求头中添加一个Origin字段,表示请求的来源。 2. 服务器响应预检请求(可选):对于某些需要特殊处理的请求(如带有自定义的头信息、使用特殊HTTP方法等),浏览器会先发送一个预检请求(OPTIONS请求),询问服务器是否允许该请求。预检请求携带了一些额外的信息,如请求方法、自定义头部等。 3. 服务器处理预检请求并返回响应:服务器接收到预检请求后,根据请求的信息判断是否允许该请求。如果允许,服务器会在响应头中添加一些字段,如Access-Control-Allow-Origin(指定允许的源)、Access-Control-Allow-Methods(指定允许的方法)等。 4. 浏览器根据响应决定是否发送真正的请求:浏览器接收到服务器的响应后,会进行判断。如果响应中包含了正确的CORS头信息,并且服务器允许该请求,浏览器会发送真正的请求。否则,浏览器会阻止真正的请求,并抛出一个错误。 需要注意的是,CORS只在浏览器中起作用,不同浏览器CORS的支持程度可能有所不同。另外,服务器端也需要进行相应的配置,以允许请求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值