跨域资源共享(CORS)

为什么会出现 CORS 规范？

1995 年，Netscape 公司在浏览器引入同源政策，出于安全原因，浏览器会限制从脚本内发起的跨源 HTTP 请求，或者跨域请求可以正常发起，但是返回结果被浏览器拦截，目前所有主流浏览器都实行该策略。

CORS 概述

跨域资源共享标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站通过浏览器有权限访问哪些资源。另外，规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求，从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括 Cookies 和 HTTP 认证相关数据）。[MDN 引用]

如何实现 HTTP 访问控制

prelight

一次 POST 请求过程
上图由 XMLHttpRequest 发出的 POST 请求的过程，浏览器检测到该请求需要被预检，所以需要发出 OPTIONS 用来获知服务器是否允许该实际请求。

下面是在 OPTIONS 的请求中，它所携带的 HTTP 首部字段 【无须手动设置，发起跨域请求时它们已经被设置就绪】

1. Origin 首部字段表明预检请求或实际请求的源站

2. Access-Control-Request-Method 将实际请求所使用的 HTTP 方法告诉服务器

3. Access-Control-Request-Headers:将实际请求所携带的首部字段告诉服务器。

下面是 OPTIONS 请求获得服务器响应后，在 HTTP 响应中的首部字段

1. Access-Control-Allow-Origin:指定了允许访问该资源的外域 URI

2. Access-Control-Expose-Headers:让服务器把允许浏览器访问的头放入白名单

3. Access-Control-Max-Age 指定了 preflight 请求的结果能够被缓存多久

4. Access-Control-Allow-Credentials 指定请求是否携带身份凭证 （cookies）

5. Access-Control-Allow-Methods 指明实际请求所允许使用的 HTTP 方法

6. Access-Control-Allow-Headers 指明实际请求中允许携带的首部字段。

更多详细资料参考 【CORS-MDN】

四，在场景分析

前后端部署在不同的服务器上，前端 XMLHttpRequest 发起跨域 HTTP 请求，同时需要携带 cookies （userName）数据，以服务器端业务处理。

• 一般而言，对于跨域 请求，浏览器不会发送 cookie，如果要请求发送 cookie，需要设置 withCredentials 特殊标志位为 true。

• 在服务端，服务器端的响应中未携带 Access-Control-Allow-Credentials: true ，浏览器将不会把响应内容返回给请求的发送者，所以服务端响应需要设置 Access-Control-Allow-Credentials: true

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

这意味着从 sit-admin.test.com 站点内 XMLHttpRequest 向 sit-gateway.test.com 站点请求数据，只能携带 sit-gateway.test.com 站点及其父域站点下的 cookie，心中一愣，这是什么鬼，我们明明想携带的是源站点（sit-admin.test.com）下的 cookie 数据。

这是因为 cookie 的作用域是 domain 本身以及 domain 下的所有子域名，所以将源站点中的 cookie 数据设置在根域 test.com 中，这样可达到我们想要的跨域 cookie 凭证传输。缺点是每次传输都会携带，浪费资源。同时设置在根域中会使一些其他子域的也会携带这样数据，所以最好的方案是减少在 cookie 中传输这样数据，可采用其他方式。