文章目录

• 同源策略
• 同源与异源
• 跨域的限制场景
• 解决方案
• • CORS
  • • 请求分类
    • • 简单请求
      • 预检请求
    • 注意点一 【关于Cookie】
    • 注意点二 【关于跨域获取响应头】
  • JSONP
  • • 基本流程
  • 代理服务器
• 如何选择对应方案

同源策略

**同源策略是一套浏览器的安全策略机制，当一个源的文档和脚本，与另一个源的资源进行通信时，同源策略就会对这个通信做出不同程度的限制。简单来说，同源策略就是对同源资源的访问请求放行，对异源资源的访问请求限制，因此限制造成的开发问题，称之为跨域（异源）问题。

点击查看W3C官方文档对同源策略的解释描述**

同源与异源

两个URL地址的源地址如果完全相同，则称之为同源，否则称之为异源（跨域）

源一

源二

是否同源

http : //www.xyz.com/home

https : //www.xyz.com/home

非同源

http : //www.xyz.com/home

http : //mail.xyz.com/home

非同源

http : //www.xyz.com:8080/home

http : //www.xyz.com:8081/home

非同源

http : //www.xyz.com:8080/home

http : //www.xyz.com:8080/info

同源

---

跨域的限制场景

• 限制 DOM 访问
• 限制 Cookie 访问（默认情况下）
• 限制 Ajax 获取资源数据

请求页面的源称之为 页面源，在该页面中发出的请求称之为 目标源。

当页面源和目标源一致时，则为 同源请求，否则为 异源请求（跨域请求）

注明：

• 跨域限制仅存在浏览器端，服务端不存在跨域限制。
• 即使跨域了，Ajax 请求也可以正常发出，但响应数据不会交给开发者。
• <link>、<script/>、<img> … 这些标签发出的请求也可能跨域，只不过浏览器对标签跨域不做严格限制，对开发几乎无影响
• 对 AJAX 发出的跨域请求严厉限制

---

解决方案

CORS

CORS（Cross-Origin Resource Sharing（跨域资源共享））: 。是最正统的跨域解决方案，同时也是浏览器推荐的解决方案。CORS是一套规则，用于帮助浏览器判断是否校验通过。

CORS的基本理念是：

• 只要服务器明确表示 允许请求，则 通过校验
• 服务器明确拒绝或没有表示，则校验不通过

所以，使用CORS解决跨域，必须要保证服务器是我方可完全控制的

请求分类

• CORS 将请求类型分为两类：简单请求和预检请求
• 对不同种类的请求它的规则有所区别。
• 所以要理解CORS，首先要理解它是如何划分请求的。

简单请求

复杂请求（预检请求（preflight））

请求方法是:GET，POST，HEAD之一

头部字段满足CORS安全规范，详见W3C安全规范文档说明
浏览器默认自带的头部字段都是满足安全规范的，只要开发者不改动和新增头部，就不会打破此条规则

如果有请求头 Content-Type，必须是下列值中的一个

text/plain

multipart/form-data

application/x-www-form-urlencoded

点击查看简单请求完整判断逻辑

只要不是简单请求，其它均为复杂（预检）请求

简单请求

对于简单请求的验证流程

预检请求

1. 发送时机：预检请求在实际跨域请求之前发出，是由浏览器自动发起的
2. 主要作用：用于向服务器确认是否允许接下来的跨域请求
3. 基本流程：先发起 OPTIONS 请求，如果通过预检，则继续发起实际的跨域请求
4. 请求头内容：一个 OPTIONS 预检请求，通常会包含如下请求头

请求头

描述

Origin

发起请求的源

Access-Control-Request-Method

实际请求的 HTTP 方法

Access-Control-Request-Headers

实际请求中使用的自定义头（如果有的话）

服务器先通过浏览器的预检请求，服务器需要返回如下响应头：

请求头

描述

Access-Control-Allow-Origin

允许的源

Access-Control-Allow-Methods

允许的的 HTTP 方法

Access-Control-Allow-Headers

实际请求中允许的自定义头

Access-Control-Max-Age

预检请求的结果缓存时间（可选）

对预检请求的验证流程

1. 发送预检请求

2. 开始发送真实请求（和简单请求一致）

---

注意点一 【关于Cookie】

默认情况下，AJAX的跨域请求并不会附带Cookie，这样一来，某些需要权限的操作就无法进行。不过可以通过简单的配置就可以实现附带Cookie

// XHR
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;// fetch api
fetch(url, {credentials: "include"
})

这样一来，该跨域的AJAX请求就是一个_附带身份凭证的请求_
当一个请求需要附带Cookie时，无论它是简单请求，还是预检请求，都会在请求头中添加Cookie字段
而服务器响应时，需要 明确告知客户端：服务器允许这样的凭据
告知的方式也非常的简单，只需要在响应头中添加：Access-Control-Allow-Credentials: true 即可。
对于一个附带身份凭证的请求，若服务器没有明确告知，浏览器仍然视为跨域被拒绝。
另外要特别注意的是：对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为*。这就是为什么不推荐使用*的原因

---

注意点二 【关于跨域获取响应头】

在跨域访问时，JS只能拿到一些最基本的响应头，如：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，如果要访问其他头，则需要服务器设置本响应头。

Access-Control-Expose-Headers头让服务器把允许浏览器访问的头放入白名单，例如：

Access-Control-Expose-Headers: authorization, a, b

配置指定过后，这样JS就能够访问指定的响应头了。

---

JSONP

JSONP 是利用了 <script> 标签可以跨域加载脚本，且不受严格限制的特性，可以说是程序员智慧的结晶，早期一些浏览器不支持 CORS 的时，可以靠 JSONP 解决跨域

基本流程

• 第一步：客户端创建一个<script>标签，并将其 src 属性设置为包含跨域请求的 URL，同时准备一个回调函数，这个回调函数用于处理返回的数据
• 服务端接收到请求后，将数据封装在回调函数中并返回
• 客户端的回调函数被调用，数据以参数的形势传入回调函数

虽然可以解决问题，但JSONP有着明显的缺陷：

• 仅能使用GET请求
• 容易产生安全隐患
  • 恶意攻击者可能利用callback=恶意函数的方式实现XSS攻击
• 容易被非法站点恶意调用

因此，除非是某些特殊的原因，否则永远不应该使用JSONP

---

代理服务器

由于同源策略只会在浏览器环境中存在，一但脱离了浏览器，则跨域不存在。所以我们可以借助于中间层代理服务器来进行请求和响应的转发

---

如何选择对应方案

基本原则：是要保持生产环境和开发环境一致。

常见几种场景：

这几种场景，始终围绕保持和生产环境和开发环境一致的基本理念。

---

??♂ 博主座右铭：向阳而生，我还在路上！
——————————————————————————————
??博主想说：将持续性为社区输出自己的资源，同时也见证自己的进步！
——————————————————————————————
??♂ 如果都看到这了，博主希望留下你的足迹！【??收藏！??点赞！评论！】
——————————————————————————————