前端网络之【浏览器跨域问题分析与解决方案】

文章目录

同源策略

**

同源策略

是一套

浏览器的安全策略机制

，当一个

源

的文档和脚本，与另一个

源

的资源进行通信时，

同源策略

就会对这个通信做出不同程度的

限制

。简单来说，

同源策略

就是

对同源资源的访问请求放行

，对

异源资源的访问请求限制

，因此限制造成的开发问题，称之为

跨域（异源）

问题。

点击查看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**

// XHRvar xhr =newXMLHttpRequest();
xhr.withCredentials =true;// fetch apifetch(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

**

代理服务器

**由于

同源策略

只会在浏览器环境中存在，一但脱离了浏览器，则

跨域

不存在。所以我们可以借助于

中间层代理服务器来进行请求和响应的转发

**

如何选择对应方案

**基本原则：是要保持

生产环境和开发环境一致

。**

常见几种场景：

**这几种场景，始终围绕保持和

生产环境和开发环境一致

的基本理念。**

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