前端百题斩【027】——解决跨域的常用利器CORS全解

27.1 简介

根据同源策略，浏览器默认是不允许XMLHttpRequest对象访问非同一站点的资源的，这会大大制约生产力，所以需要有一种机制允许跨域访问资源，然后我们的主角CORS（跨域资源共享）就出现了，该机制可以进行跨域访问控制，从而使跨域数据传输得以安全进行。

27.2 整体流程

CORS的通信流程是浏览器自动完成，不需要用户参与，其核心点是服务器，只要服务器实现了CORS接口就可以实现跨源通信了。虽然是浏览器自动完成，但是浏览器其实还是根据请求时字段的不同分为简单请求和非简单请求的，下面对这两者进行简要介绍。

27.2.1 简单请求

27.2.1.1 定义

只要满足以下两个条件就属于简单请求：

1. 请求方法是一下三种方法之一：HEAD、GET、POST；
2. HTTP的头信息不超出以下几种字段：Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type（其值为application/x-www-form-urlencoded、multipart/form-data、text/plain三个中的一个）。

27.2.1.2 流程

简单请求的整个流程可以归结为以下步骤：

1. 浏览器直接发出CORS请求，具体来说就是在头信息之中增加一个Origin字段，该字段用来说明请求来自哪个源（协议+域名+端口），服务器根据这个值决定是否同意这次请求；
2. 当服务器接收到请求后，根据Origin判定指定的源是否在许可的范围内。
3. 如果不在许可范围内，服务器会返回一个正常的HTTP回应，浏览器发现该回应的头信息没有包含Access-Control-Allow-Origin字段，就知道出错了，从而抛出错误，被XML的onerror回调函数捕获。（注意：由于正常回应，其状态码为200，所以该错误不能通过状态码识别）
4. 如果Origin指定的域名在许可范围内，服务器返回的响应中会多出几个头信息字段（Access-Control-Allow-Origin、Access-Control-Allow-Credentials、Access-Control-Expose-Header等）。

27.2.1.3 关键字段

1. Access-Control-Allow-Origin

必须字段，该值要么是请求的Origin字段值，要么是一个*（表示接受任意域名的请求）。

2. Access-Control-Allow-Credentials

可选字段，其值是一个布尔值，表示是否允许发送Cookie。默认是不发送Cookie值，当设置为true时，表示服务器明确许可，Cookie可以包含在请求中发送给服务器。（注意：发送Cookie时要注意两点：一方面在Ajax请求中需要设置withCredentials属性；另一方面不能将Access-Control-Allow-Origin设置为*,需要指定明确的、与请求网页一致的域名）

3. Access-Control-Expose-Header

可选字段，当CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段（Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma），如果想获取其它字段必须在Access-Control-Expose-Header中指定。

27.2.2 非简单请求

27.2.2.1 定义

不是简单请求的就是非简单请求，非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或Delete，或者Content-Type字段的类型是application/json.

27.2.2.2 流程

非简单请求相比于简单请求较复杂，在发起正式请求之前会进行一次预检请求，通过预检请求的结果来决定是否进行后续的正式通信。

1. 浏览器发起预检请求，该请求的请求方法是options，该请求是用来询问的；
2. 服务器收到“预检”请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。
3. 如果浏览器否定了“预检”请求，会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段，这时浏览器就会认定服务器不同意预检请求，触发错误；
4. 如果浏览器通过了“预检”请求，以后每次浏览器正常的CORS请求就跟简单请求一样，会有一个Origin头信息字段，服务器的回应也会有一个Access-Control-Allow-Origin头信息字段；

27.2.2.3 关键字段

1. Access-Control-Request-Method

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

2. Access-Control-Request-Headers

该字段是一个逗号分隔的字符串，用来指定浏览器CORS请求会额外发送的头信息字段。

3. Access-Control-Allow-Methods

必须字段，该值是一个逗号分隔的字符串，用来表明服务器支持的所有跨域请求的方法。

4. Access-Control-Allow-Headers

该值是一个逗号分隔的字符串，表明服务器支持的所有头信息字段。

5. Access-Control-Max-Age

用来请求预检请求的有效期，单位为秒。

27.3 实验

27.3.1 实验一

实验目的:

1. 非同源会产生跨域问题
2. 跨域是浏览器对响应拦截造成的

1. 首先来看看浏览器控制台内容

控制台内容显示报错，报错内容是跨域，这是因为端口不同（一个8009一个8010），两者不同源，所以导致跨域，验证了实验目的1.

2. 紧接着来瞅瞅服务器控制台打印了啥内容

控制台内容打印了接收到了get请求，则证明浏览器的请求发出了并被服务器端正常接收，从侧面证明了跨域是浏览器对响应进行了拦截，从而验证了实验目的2.

27.3.2 实验二

实验目的

1. 服务器配置Access-Control-Allow-Origin会解决跨域问题
2. 浏览器通过响应头中是否包含Access-Control-Allow-Origin这个响应头的值与请求头中Origin是否相等来确定是否能够进行跨域访问

1. 首先来搂一眼请求头

紧接着再来搂一眼响应头

按照理论来说，请求头中的Origin字段表示本次请求来自哪个源（协议+域名+端口），服务器根据这个值来决定是否同意这次请求。如果Origin指定的源不在许可范围内，服务器会返回一个正常的HTTP回应。目前并没有修改，还处于报错状态，该响应确实是一个正常响应，不包含Access-Control-Allow-Origin字段，但是这也不足以说服我浏览器是通过验证该字段来确实是否允许跨域请求。所以紧接着需要做一个对比试验，通过修改服务端的代码后观察响应头内容。

3. 从最简单的修改开始，直接将响应头中加入Access-Control-Allow-Origin=“http://127.0.0.1:8009” 字段，理论上来说此时会允许所有的跨域请求。

服务端代码修改后内容

app.get('/', (req, res) => {
    console.log('get请求收到了！！！');
    res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:8009');
    res.send('get请求已经被处理');
})

响应头内容

观察到响应头中多了一行内容：Access-Control-Allow-Origin：http://127.0.0.1:8009 字段，在看看响应内容，确实有消息返回了，内容如下：

4. 只验证了Origin和Access-Control-Allow-Origin中内容响应，若内容不同又会有什么现象呢？

服务端代码进一步修改

.get('/', (req, res) => {
    console.log('get请求收到了！！！');
    res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:8008');
    res.send('get请求已经被处理');
})

响应头内容

此时浏览器控制台报错了，出现了跨域问题

通过该实验可以验证通过配置Access-Control-Allow-Origin字段可以解决跨域问题；此外，浏览器是通过检查响应头中Access-Control-Allow-Origin字段的值与Origin的值是否相等来确定是否允许跨域访问的。通过该实验达到了我们实验的目的。

27.3.3 实验三

实验目的 验证CORS请求默认不发送Cookie信息，如果要把Cookie发送到服务器，一方面要服务器同意（通过指定Access-Control-Allow-Origin字段且Access-Control-Allow-Origin需要指定具体域名）；另一方面浏览器请求中必须带上withCredentials字段。

1. 通过观察请求头（看实验一中请求头），并不包含Cookie信息

2. 代码修改

index.html页面进行修改

axios('http://127.0.0.1:8010', {
    method: 'get',
    withCredentials: true
}).then(console.log)

服务器端代码修改

app.get('/', (req, res) => {
    console.log('get请求收到了！！！');
    console.log('cookie 内容为', req.headers.cookie);
    res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:8009');
    res.setHeader('Access-Control-Allow-Credentials', true);
    res.cookie('test', 'test', {expires: new Date(Date.now() + 900000)});
    res.send('get请求已经被处理');
})

3. 再次观察请求头内容，带上了cookie
   

看看服务器端有没有接收到cookie信息，控制台信息如下，确实收到了cookie信息

按照上述进行配置发送请求过程中将会带着cookie信息，上一个配置将会报错（可以自行验证）

27.3.4 实验四

实验目的

1. 验证非简单请求会增加一次预检请求
2. 预检请求是Options请求
3. 请求头中会携带非简单请求的请求方法（Access-Control-Request-Methods）和头信息（Access-Control-Request-Headers），预检请求的响应头信息中Access-Control-Allow-Methods和Access-Control-Allow-Headers与上述请求头中的信息匹配才可以发送正常的CORS请求。

1. 第一步肯定是要修改代码了

index.html代码

axios('http://127.0.0.1:8010', {
    method: 'post',
    headers: {
        'Content-Type': 'application/json'
    },
    data: {
        name: 'dog'
    }
}).then(console.log)

服务器代码修改如下

app.options('/', (req, res) => {
    console.log('options请求收到了！！！');
    res.setHeader('Access-Control-Allow-Origin', '*');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type');
    res.setHeader('Access-Control-Max-Age', 10000);
    res.send('options请求已经被处理');
});
app.post('/', (req, res) => {
    console.log('post请求收到了！！！');
    res.setHeader('Access-Control-Allow-Origin', '*');
    res.send('post请求已经被处理');
});

2. 修改完了代码是不是要瞅瞅结果呢？

先看看浏览器是不是输出了内容,确实有内容输出了

再瞅瞅服务器输出了些什么内容

可以看到本来打算发一次请求，但实际上发了两条，第一条是Options请求，第二条请求才是post请求，上述打印内容验证了实验目的中的一和二。

3. 下面继续深入思考，来看看预检请求的请求头和响应头

请求头内容

上述Access-Control-Request-Headers与Access-Control-Allow-Headers一样，而且内容也正常返回了（步骤二中已经进行了展示），但是这不足以证明实验目的三，下面我们认为增加一条头信息再来看结果。

4. 人为增加一条请求头信息

index.html页面修改后如下

axios('http://127.0.0.1:8010', {
    method: 'post',
    headers: {
        'Content-Type': 'application/json',
        'Test': 'test'
    },
    data: {
        name: 'dog'
    }
}).then(console.log)

此时浏览器控制台报错了

服务端只接收到了options请求

请求头信息为

响应头信息为

通过该实验证明只有Access-Control-Request-Headers与Access-Control-Allow-Headers相等的时候，预检请求才会通过，后续请求才会发出，从而达到了该实验的实验目的三。