
文章目录
- 同源策略
- 同源与异源
- 跨域的限制场景
- 解决方案
-  - 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
代理服务器
由于
同源策略只会在浏览器环境中存在,一但脱离了浏览器,则跨域不存在。所以我们可以借助于中间层代理服务器来进行请求和响应的转发

如何选择对应方案
基本原则:是要保持
生产环境和开发环境一致。

常见几种场景:


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

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