详解CORS跨域内部机制，克服浏览器同源策略

CORS跨域，它的全称是"跨域资源共享"(Cross-origin resource sharing）。

跨域案例

页面地址:http://client.cors.com:8000/greeter.html，代码如下：

服务器接口地址：http://server.cors.com:3000/data，服务器代码如下：

很明显，当页面在请求服务器接口时会发生跨域现象，如下图3所示：

我们去浏览器Network中看一下请求信息:

如上图所示，响应为200，response Headers信息也很正常，这说明在跨域的情况下请求依然可以到达服务器，并且服务器能够正常响应，但是由于浏览器的同源策略并没有把返回的数据给到页面。

那么如何让页面在跨域的情况下获取到数据呢？我们回看图3，似乎在说少了一个Access-Control-Allow-Origin头，那么我们在服务器代码中加一下。

现在刷新页面，服务器返回的数据就能正常打印出来了。

携带凭证

在跨域的情况，服务器有时依然需要鉴权。通常服务器鉴权都是从cookie中获取信息来判断客户端的身份，那么跨域的情况下请求还能传递cookie吗？当然能，但是cookie会遵守同源策略！
2.1 服务器设置cookie

如果需要服务器设置cookie，必须设置Access-Control-Allow-Credentials: true，否则会出现如下错误:

页面中的xhr对象也必须设置属性withCredentials=true。
此时刷新页面，在页面控制台中通过document.cookie查看server=123，你会发现server端设置的cookie并不存在。上面已经说了cookie会遵循同源策略，服务器的域名是server.cors.com，所以服务器设置的cookie应该是在这个域名下，并不会在页面的域名（client.cors.com）下，那如何验证服务器设置cookie成功呢？
先打开接口页面，这个页面是同源的；回到请求页面，刷新；再回到接口页面，在控制台通过document.cookie就可以拿到服务器设置的cookie。

如下图所示这样：

2.2 页面设置cookie
如果主域名相同，比如现在的例子，主域名都是cors.com，那么就可以把cookie设置在这个主域名下。

这样服务器就能获取到页面设置的cookie。

如果连主域名都不一样，那就不要妄想在页面上设置cookie让服务器获取到。这种情况下，服务器该如何鉴权呢？
第一种方式是让后端把跨域的接口代理成同域的，这样我们的后端可以拿到cookie，在他那把cookie转发给跨域服务。

第二种方式是页面发送请求时在header中附加一个token，用于鉴权，如下图所示:

当刷新页面时，页面控制台又报错了:

提示设置Access-Control-Allow-Headers，那我们就设置一下:

再刷新页面，请求正常了，服务端也能拿到token的值了。

简单请求与非简单请求

在上面的第二种方式，页面发送请求时在header中加上一个token，用于鉴权，然后服务端加上Access-Control-Allow-Headers：‘token’，这样我们就能拿到token了，此时我们再去瞧瞧浏览器中的Network，会发现页面发送了两个请求，第一个请求的method是OPTIONS，这是怎么回事呢？

原来cors跨域也分简单请求和非简单请求。

简单请求条件如下：

请求方法是必须是HEAD/GET/POST三种方法之一；
HTTP的头信息不超出这几种字段：Accept/Accept-Language/Content-Language/Content-Language/Last-Event-ID/Content-Type，Content-Type只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain。

在上面的第二种方式中我们设置了token请求头，显然不满足以上条件，所以是非简单请求。非简单请求的CORS请求会在正式通信之前增加一次HTTP查询请求，称为预检请求（preflight）。浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。预检请求用的请求方法是OPTIONS，表示这个请求是用来询问的。

我们现在尝试发送一次PUT请求，看看会有什么现象？

不出所料，浏览器再次报错！

提示我们设置Access-Control-Allow-Methods，那就只能设置了！

再次刷新页面，现在请求正常了！我们回头看一下预检请求：

不得不说，浏览器在访问跨域接口时真的是非常的小心，当然这一切都是为了安全考虑。即使这样，现在网络中也不乏XSS、CSRF等攻击。