跨域资源共享(CORS)

为什么会出现 CORS 规范?

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

CORS 概述

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

如何实现 HTTP 访问控制

一次 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 中传输这样数据,可采用其他方式。