文章目录
- 同源策略
- 同源与异源
- 跨域的限制场景
- 解决方案
-
- 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
点击查看简单请求完整判断逻辑
只要不是简单请求，其它均为复杂（预检）请求
简单请求
对于简单请求的验证流程
预检请求
- 发送时机：预检请求在
实际跨域请求之前发出，是由浏览器自动发起的 - 主要作用：用于向服务器确认
是否允许接下来的跨域请求 - 基本流程：先发起
OPTIONS请求，如果通过预检，则继续发起实际的跨域请求 - 请求头内容：一个
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
代理服务器
由于
同源策略只会在浏览器环境中存在，一但脱离了浏览器，则跨域不存在。所以我们可以借助于中间层代理服务器来进行请求和响应的转发
如何选择对应方案
基本原则：是要保持
生产环境和开发环境一致。
常见几种场景：
这几种场景，始终围绕保持和
生产环境和开发环境一致的基本理念。
??♂ 博主座右铭：向阳而生，我还在路上！
——————————————————————————————
??博主想说：将持续性为社区输出自己的资源，同时也见证自己的进步！
——————————————————————————————
??♂ 如果都看到这了，博主希望留下你的足迹！【??收藏！??点赞！评论！】
——————————————————————————————
