【WEB】浏览器同源策略及跨域资源共享(CORS)

本文主要参考

• 跨域资源共享 CORS 详解

浏览器的同源策略一直以来都是Web安全的基础，但这同时也制约了Web研发的一部分功能，特别是现在大多数网站都采用前后端分离的架构，因此很多时候前端需要跨域去获取一些资源或者接口数据，这时候就不得不想办法规避浏览器的同源策略。作为一名合格的Coder，肿么可以不去好好了解它咧~~~

一、同源策略（Same-origin policy）

1.1 概述

打个简单的比喻就是：如果我在浏览器同时访问新浪和搜狐两个网站并且这两个网站都在浏览器存储了用户名和密码，那么他们各自只能访问各自存储的用户信息，无法交叉访问，否则就会造成用户信息泄露（现在同源策略的限制远不止这一点）。

1.2 定义

一个URL的通用格式由9部分构成（想深入了解的童鞋请看《HTTP权威指南》第二章）：

• <scheme[方案协议]>://<user[用户名]>:<password[密码]>@<host[主机域名]>:<port[端口号]>/<path[路径]>;<params[参数]>?<query[查询]>#<frag[片段]>

对于同源的定义主要看三点：

1. 协议相同
2. 域名相同
3. 端口相同

举例来说， http://www.jianshu.com/p/43362635aee2 这个网址中， http 是协议， www.jianshu.com 是域名，端口是80（http协议默认端口可以省略，你也可以把他看成：http://www.jianshu.com:80/p/43362635aee2）。任意两个网址，只要这三点全部相同，那么浏览器就认为它们是同源的，任意一个不相同都会被浏览器认为是跨域。

注：IE例外

IE浏览器对于同源策略有两个主要的例外：

1. 授信范围（Trust Zones）：两个相互之间高度互信的域名，如公司域名（corporate domains），不遵守同源策略的限制。
2. 端口：IE浏览器没有将端口号加入到同源策略的组成部分之中，因此 http://example.com:81/index.html 和 http://example.com/index.html 属于同源并且不受任何限制。

1.3 限制范围

如果两个请求非同源，将会受到以下三种行为限制：

1. Cookie、LocalStorage 和 IndexDB 无法读取。
2. DOM 无法获得。
3. AJAX 请求不能发送。

二、跨域网络访问

2.1 源修改——共享Cookie

页面可能会更改其自己的来源，但有一些限制。脚本可以将document.domain的值设置为其当前域或其当前域的超级域，这样可以实现所有一级域名相同的网页一起共享Cookie。
举例来说，A网页是http://w1.example.com/a.html，B网页是http://w2.example.com/b.html，那么只要设置相同的document.domain，两个网页就可以共享Cookie。

document.domain = 'example.com';

现在，A网页通过脚本设置一个 Cookie。

document.cookie = "test1=hello";

B网页就可以读到这个 Cookie。

var allCookie = document.cookie;

2.2 window.postMessage——跨文档通信

HTML5引入了一个全新的API：跨文档通信 API（Cross-document messaging）。这个API为window对象新增了一个window.postMessage方法，允许跨窗口通信，不论这两个窗口是否同源。
举例来说，父窗口http://aaa.com向子窗口http://bbb.com发消息，调用postMessage方法就可以了。

var popup = window.open('http://bbb.com', 'title');
popup.postMessage('Hello World!', 'http://bbb.com');

postMessage方法的第一个参数是具体的信息内容，第二个参数是接收消息的窗口的源（origin），即"协议 + 域名 + 端口"。也可以设为*，表示不限制域名，向所有窗口发送。
子窗口向父窗口发送消息的写法类似。

window.opener.postMessage('Nice to see you', 'http://aaa.com');

父窗口和子窗口都可以通过message事件，监听对方的消息。

 window.addEventListener('message', function(e) {
   console.log(e.data);
 },false);

message事件的事件对象event，提供以下三个属性。

• event.source：发送消息的窗口
• event.origin: 消息发向的网址
• event.data: 消息内容

下面的例子是，子窗口通过event.source属性引用父窗口，然后发送消息。

window.addEventListener('message', receiveMessage);
function receiveMessage(event) {
 event.source.postMessage('Nice to see you!', '*');
} 

event.origin属性可以过滤不是发给本窗口的消息。

window.addEventListener('message', receiveMessage);
function receiveMessage(event) {
  if (event.origin !== 'http://aaa.com') return;
  if (event.data === 'Hello World') {
      event.source.postMessage('Hello', event.origin);
  } else {
    console.log(event.data);
  }
} 

2.3 JSONP——跨域通信

JSONP跨域通信是利用<script>标签没有跨域限制的“漏洞”来达到与第三方通讯的目的。它的基本思想是，网页通过添加一个<script>元素，向服务器请求JSON数据，服务器收到请求后，将数据以json形式进行包装（故称之为jsonp，即json padding），然后放在一个指定名字的回调函数里传回来，形如：callback({"name":"Liqing","nickname":"Newbie"})这样浏览器会调用callback函数，并传递解析后json对象作为参数。
首先，本站脚本创建一个<script>元素，由它向跨源网址发出请求:

function addScriptTag(src) {
  var script = document.createElement('script');
  script.setAttribute("type","text/javascript");
  script.src = src;
  document.body.appendChild(script);
}

window.onload = function () {
  addScriptTag('http://example.com/ip?callback=foo');
}

function foo(data) {
  console.log('Your public IP address is: ' + data.ip);
};

上面代码通过动态添加<script>元素，向服务器example.com发出请求。注意，该请求的查询字符串有一个callback参数，用来指定回调函数的名字，这对于JSONP是必需的。
服务器收到这个请求以后，会将数据放在回调函数的参数位置返回。

foo({
  "ip": "8.8.8.8"
});

由于<script>元素请求的脚本，直接作为代码运行。这时，只要浏览器定义了foo函数，该函数就会立即调用。作为参数的JSON数据被视为JavaScript对象，而不是字符串，因此避免了使用JSON.parse的步骤。

2.4 WebSocket——跨域通信

WebSocket是HTML5开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。在WebSocket API中，浏览器和服务器只需要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。
WebSocket目前由W3C进行标准化。WebSocket已经受到Firefox 4、Chrome 4、Opera 10.70以及Safari 5等浏览器的支持。
WebSocket API最伟大之处在于服务器和客户端可以在给定的时间范围内的任意时刻，相互推送信息。WebSocket并不限于以Ajax(或XHR)方式通信，因为Ajax技术需要客户端发起请求，而WebSocket服务器和客户端可以彼此相互推送信息；XHR受到域的限制，而WebSocket允许跨域通信。

三、跨域Ajax之根本解决方案——跨域资源共享(Cross-origin resource sharing)

跨域资源共享(CORS)是一个W3C标准，可以说它的诞生就是为了解决Ajax跨域请求问题的。CORS与JSONP相比:

1. JSONP只能实现GET请求，而CORS支持所有类型的HTTP请求。
2. 使用CORS，开发者可以使用普通的XMLHttpRequest发起请求和获得数据，比起JSONP有更好的错误处理。
3. JSONP主要被老的浏览器支持，但它们往往不支持CORS，而所有现代浏览器都支持CORS(IE浏览器不能低于IE10)。

3.1 概述

整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。
因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨域通信。
浏览器的CORS请求主要分为两种：简单请求和非简单请求，只要同时满足以下两大条件，就属于简单请求。
① 请求方法是以下三种方法之一：

• HEAD
• GET
• POST

② HTTP的头信息不超出以下几种字段：

• Accept
• Accept-Language
• Content-Language
• Last-Event-ID
• Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、 text/plain

凡是不同时满足上面两个条件，就属于非简单请求，一个非简单请求不仅有包含通信内容的请求，同时也包含预请求（preflight request，即:请求两次）。

3.2 简单请求

简单请求的发送从代码上来看和普通的XHR没太大区别，但是HTTP头当中要求总是包含一个域（Origin）的信息。该域包含协议名、地址以及一个可选的端口。不过这一项实际上由浏览器代为发送，并不是开发者代码可以触及到的，例如：

GET  /source HTTP/1.1
Origin: http://api.test.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

上面的头信息中，Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。如果服务端返回的HTTP响应头中没有Access-Control-Allow-Origin字段，那么浏览器便会认为没有跨域访问该资源的权限，抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。
如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。

• Access-Control-Allow-Origin（必须）- 不可省略，否则请求按失败处理。该项控制数据的可见范围，如果希望数据对任何人都可见，可以填写"*"。
• Access-Control-Allow-Credentials（可选） – 该项标志着请求当中是否包含cookies信息，只有一个可选值：true（必为小写）。如果不包含cookies，请略去该项，而不是填写false。这一项与XmlHttpRequest2对象当中的withCredentials属性应保持一致，即withCredentials为true时该项也为true；withCredentials为false时，省略该项不写。反之则导致请求失败。
• Access-Control-Expose-Headers（可选） – 该项确定XmlHttpRequest2对象当中getResponseHeader()方法所能获得的额外信息。通常情况下，getResponseHeader()方法只能获得如下的信息：
  上面说到，CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。

Access-Control-Allow-Credentials: true

另一方面，开发者必须在AJAX请求中打开withCredentials属性。

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。
但是，如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials。

xhr.withCredentials = false;

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

3.3非简单请求

3.3.1预检请求

非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为预检请求（preflight）。
浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。
预请求以OPTIONS形式发送，当中同样包含域，并且还包含了两项CORS特有的内容：

• Access-Control-Request-Method – 该项内容是实际请求的种类，可以是GET、POST之类的简单请求，也可以是PUT、DELETE等等。
• Access-Control-Request-Headers – 该项是一个以逗号分隔的列表，当中是复杂请求所使用的头部。
  上面代码中，HTTP请求的方法是PUT，并且发送一个自定义头信息X-Custom-Header。

浏览器发现，这是一个非简单请求，就自动发出一个"预检"请求，要求服务器确认可以这样请求。下面是这个"预检"请求的HTTP头信息。

OPTIONS /source HTTP/1.1
Origin: http://api.test.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

"预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。

除了Origin字段，"预检"请求的头信息包括两个特殊字段。

① Access-Control-Request-Method

该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT。

② Access-Control-Request-Headers

该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是X-Custom-Header。
显而易见，这个预请求实际上就是在为之后的实际请求发送一个权限请求，在预回应返回的内容当中，服务端应当对这两项进行回复，以让浏览器确定请求是否能够成功完成。

3.3.2 预检请求预检请求的回应

服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。

非简单请求的部分响应头及解释如下：

• Access-Control-Allow-Origin（必含） – 和简单请求一样的，必须包含一个域。
• Access-Control-Allow-Methods（必含） – 这是对预请求当中Access-Control-Request-Method的回复，这一回复将是一个以逗号分隔的列表。尽管客户端或许只请求某一方法，但服务端仍然可以返回所有允许的方法，以便客户端将其缓存。
• Access-Control-Allow-Headers（当预请求中包含Access-Control-Request-Headers时必须包含） – 这是对预请求当中Access-Control-Request-Headers的回复，和上面一样是以逗号分隔的列表，可以返回所有支持的头部。这里在实际使用中有遇到，所有支持的头部一时可能不能完全写出来，而又不想在这一层做过多的判断，没关系，事实上通过request的header可以直接取到Access-Control-Request-Headers，直接把对应的value设置到Access-Control-Allow-Headers即可。
• Access-Control-Allow-Credentials（可选） – 和简单请求当中作用相同。
• Access-Control-Max-Age（可选） – 以秒为单位的缓存时间。预请求的的发送并非免费午餐，允许时应当尽可能缓存。

如果浏览器否定了"预检"请求，会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被XMLHttpRequest对象的onerror回调函数捕获。

3.3.3 浏览器的正常请求和回应

一旦服务器通过了"预检"请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。
下面是"预检"请求之后，浏览器的正常CORS请求。

PUT /source HTTP/1.1
Origin: http://api.test.com
Host: api.alice.com
X-Custom-Header: value
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

上面头信息的Origin字段是浏览器自动添加的。
下面是服务器正常的回应。

Access-Control-Allow-Origin: http://api.test.com
Content-Type: text/html; charset=utf-8

上面头信息中，Access-Control-Allow-Origin字段是每次回应都必定包含的。

注：文中如有任何错误，请各位批评指正！