您当前的位置:首页 > 电脑百科 > 程序开发 > 编程百科

细解跨域以及跨域的解决方案

时间:2023-05-06 14:05:47  来源:  作者:尚硅谷教育

跨域,对于正在学习或者已经就业的前端同学而言,就是老朋友。只要涉及“请求”“前后端交互”“开发阶段”等关键字,都避不开跨域。同时它也是面试中最常出现的考点之一,面试官可以通过跨域,了解应聘者对网络协议、网络安全等概念的理解。

跨域并不是阻碍前后端交互的障碍,什么是跨域,怎么避开跨域带来的不便,本文主要细解三种主流的解决方案:JSONP,CORS,代理服务器,细致地解开跨域相关的迷惑。

一、同源策略

同源策略是一个重要的安全策略,它用于限制一个Origin的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档,减少可能被攻击的媒介。

Origin:指web文档的来源,Web 内容的来源取决于访问的URL的方案 (协议),主机 (域名) 和端口定义。只有当方案,主机和端口都匹配时,两个对象具有相同的起源。

二、跨域

关于URL是否同源,根据上图中的①②③进行判断即可,只要有一点不同,就达到跨域的条件。顺带一提,即便是向域名对应的ip进行资源请求,仍然会跨域。

IE的特殊性:Inte.NET Explorer 的同源策略有两点差异,一是IE未将端口号纳入同源策略的检查,其次是两个高度互信的域名也不受同源策略的检查。

常见的跨域情景:

浏览器内常见的跨域报错:

跨域出现的场景:

一般常见于开发阶段,本地启动项目后,当前页面域名和后台服务器域名不相同,导致跨域。在项目上线后,会通过统一域名、后端配置域名白名单等方式避免跨域。

下方的解决方案中,我们通过koa2框架搭建服务器,实现一系列的情景模拟。

三、跨域的解决方案

1.JSONP

原理:通过script标签没有跨域限制的特性,进行资源的请求和获取。

限制:需要目标服务器进行配合,且仅支持get请求

我们直接通过代码和注释,理解jsonp的使用前端代码如下:

<script>

window.jsonp = function(res){

console.log(res);

}

</script>

<script src="http://localhost:9527/jsonp?val=123&cb=jsonp"></script>

后端代码如下:

// 定义jsonp接口

router.get('/jsonp', async (ctx, next) => {

/*

1.后端通过query获取前端传来的请求参数

其中包括:

· 交予后端进行功能逻辑操作的数据,如val

· 交予后端进行jsonp操作的函数名,如cb

*/

const {cb, val} = ctx.query

// 2.调用回调函数,进行传参,将处理好的数据返回给前端

if(val === '123'){

const requestData = {

code: 10001,

data: '登陆成功'

}

//在响应体中触发目标函数,并将处理好的数据requestData作为实参传入

ctx.body = `${cb}(${JSON.stringify(requestData)})`;

}

})

前端通过window对象,在全局挂载了一个待触发的函数。

后端通过响应体触发这个函数,并将数据作为入参,传给前端。

了解简单的实现后,前端可以对jsonp的功能再进行一层封装:

/*

1. 生成script标签,我们需要script标签进行接口的调用

2. 处理参数数据,分别整理好接口,接口参数,函数名等数据,并进行填充

3. 写入生成好的script标签,实现接口的调用(返回promise对象,便于链式调用)

4. 清除script标签

*/

function jsonp(requestData) {

// 对传入参数进行处理

const { url, data, jsonp } = requestData;

let query = '';

for (let key in data) {

query += `${key}=${data[key]}&`;

}

const src = `${url}?${query}jsonp=${jsonp}`;

// 生成、填充script标签,在页面中挂载调用接口

let scriptTag = document.('script');

scriptTag.src = src;

document.body.(scriptTag);

return new Promise((resolve, reject) => {

window[jsonp] = function(rest){

resolve(rest)

document.body.removeChild(scriptTag)

}

})

}

// 整理数据

const requestData = {

url: 'http://localhost:9527/jsonp',

data: {

val: 123,

},

jsonp: 'getMessage'

}

// 接口调用

btn.onclick = function () {

jsonp(requestData).then(function (response) {

console.log(response);

})

}

2.CORS

Cross-Origin Resource sharing(跨域资源共享),是一种基于HTTP头的机制,该机制允许服务器标示除了它自己以外其他origin(域名,协议和端口),既浏览器在跨域的情景下仍然能从目标服务器请求并获取资源。

而对服务器数据可能产生副作用的HTTP请求方法,都会触发CORS中的预检机制。

CORS中通过预检机制(preflight request)检查服务器是否允许浏览器发送真实请求,浏览器会先发送一个预检请求(option请求),请求中会携带真实请求的请求信息:

origin:请求的来源

Access-Control-Request-Method:

通知服务器在真正的请求中会采用哪种HTTP方法(GET,POST,DELETE...)

Access-Control-Request-Headers:通知服务器在真正的请求中会采用哪些请求头

服务器可以在预检请求中,可以根据以上三条信息,确定预检请求是否通过:

//server.js

App.use(async (ctx, next) => {

// 允许跨域资源共享的白名单

const whiteList = ['http://127.0.0.1:5500']

// 判断目标源是否通行

const pass = whiteList.includes(ctx.header.origin)

// 对于预检请求,如果没有设置正确的响应状态,浏览器会直接拦截真实请求,直接报错提示跨域

// 所以我们可以在这一部分,确定客户端的请求是否符合我们的要求

if (ctx.method === "OPTIONS") {

if (!pass) return

// 预检放行

ctx.status = 204

}

await next();

});

响应的状态码是决定预检请求是否通过的关键,返回正常的状态码(通常是204)就能通过预检请求,让浏览器发出真实的请求。

在代码中也可以看出,pass是决定预检请求的关键,那在实际的项目中,还得根据设计去决定通行的具体条件。当通过预检请求后,后台可以设置对应的响应头数据,例如是否允许目标源跨域资源共享:

//server.js

app.use(async (ctx, next) => {

console.log('middleware for cors');

// 允许跨域资源共享的白名单

const whiteList = ['http://127.0.0.1:5500']

// 判断目标源是否通行

const pass = whiteList.includes(ctx.header.origin)

// 对于预检请求,如果没有设置正确的响应状态,浏览器会直接拦截真实请求,直接报错跨域

// 所以我们可以在这一部分,确定客户端的请求是否符合我们的要求

if (ctx.method === "OPTIONS") {

if (!pass) return

// 预检放行

ctx.status = 204

}

// 允许访问的origin

ctx.set("Access-Control-Allow-Origin", ctx.headers.origin);

// cookie是否允许携带

ctx.set("Access-Control-Allow-Credentials", true);

// 允许访问的HTTP方法

ctx.set("Access-Control-Request-Method", "PUT,POST,GET,DELETE,OPTIONS");

// 哪些请求头允许通行

ctx.set(

"Access-Control-Allow-Headers",

"X-Requested-With,Content-Type,Accept,Origin"

);

// 暴露给客户端的响应头信息,在不设置的情况下,客户端只能获取默认的响应头,如’content-type‘

ctx.set(

"Access-Control-Expose-Headers",

"With-Requested-Key"

);

// 设置对应的响应头数据

ctx.set(

"With-Requested-Key",

"HW"

);

// 预检结果的缓存时间,毫秒为单位,Firefox上限是86400-24小时,Chromium(谷歌引擎)上限是7200-2小时

ctx.set("Access-Control-Max-Age", 0);

await next();

});

其中需要注意两个点:

关于Access-Control-Expose-Header

使用CORS时,浏览器只允许获取默认的响应头,像上文代码中的标头With-Requested-Key,即便我们可以通过浏览器的调试器查看,也无法通过代码去获取,这时候就需要后台通过Access-Control-Expose-Header进行暴露(后台代码在已在上方统一贴出)。

前端代码

<body>

<button id="btn"> 请求资源 </button>

</body>

<script>

btn.onclick = function () {

axIOS.post('http://localhost:9527/getMessage', {

firstName: 'Fred',

lastName: 'Flintstone'

})

.then(function (response) {

// 可以在里面查找到暴露出来的响应头数据,如’With-Requested-Key‘: "HW"

console.log(response.headers);

})

.catch(function (error) {

console.log(error);

});

}

</script>

关于Access-Control-Allow-Credentials

使用CORS时,默认不携带cookie,需要同时满足三个条件,才能在使用CORS时进行cookie的传递:

浏览器的请求中,设置withCredentials参数为true

服务端设置标头Access-Control-Allow-Credentials为true

服务端设置标头Access-Control-Allow-Origin不为*

我们可以在原生ajax请求中设置该参数,或者在axios的默认配置中设置该参数:

// 原生ajax

const xhr = new ()

xhr.withCredentials = true

// axios

axios.defaults.withCredentials = true;

Ok,明白CORS的作用,以及明白CORS中的预检机制后,接下来是了解什么时机下会触发预检机制。

CORS中归纳了一系列不会触发预检机制的请求场景,即满足所有下述条件的情况下,统称为简单请求:

使用这三种方法之一:GET HEAD POST

不得人为设置此集合外的其他首部字段:Accept Accept-Language Content-Language Content-Type

Content-type的值仅限于这三者之一:

text/plain

multipart/form-data

application/x-www/form-urlencoded

请求中,实例没有注册任何事件监听器,即实例对象可以使用.upload属性进行访问

请求中没有使用ReadableStream对象

小结:CORS中主要区分了简单请求和复杂请求两种情况,复杂请求会触发CORS的预检机制。通过上方的案例,也可以清楚CORS的配置主要是在服务端,但客户端也需要知道CORS的使用注意点,例如响应头数据的获取以及cookies的携带配置,这些知识应该是前后端都需要掌握的技能点。

3.服务器代理

同源策略主要是限制浏览器和服务器之间的请求,服务器与服务器之间并不存在跨域。

我们可以通过koa2模拟和实现这种概念:

//前端代码

<body>

<button id="btn"> 请求资源 </button>

<script>

btn.onclick = function () {

let url = checkUrlProxy('http://localhost:9527/api/getMessage','api')

axios.post(url, {

firstName: 'Fred',

lastName: 'Flintstone'

})

.then(function (response) {

console.log(response);

})

}

// 判断接口是否携带api字段,若是,则更改为代理服务器对应的域名

function checkUrlProxy(url, proxyFlag){

let proxyServer = 'http://localhost:1005'

let urlArr = [url.split('/')[1],url.split('/')[3]]

if(urlArr.includes(proxyFlag)) {

return `${proxyServer}/${proxyFlag}${url.split(proxyFlag)[1]}`

}

return url

}

//

</script>

</body>

前端的代码部分,通过checkUrlProxy函数简单地确定本次请求是否要转向代理服务器。

后端代码如下:

//proxyServer.js

let requestFlag = false

let body = ''

app.use(async (ctx, next) => {

// 全放行

if (ctx.method === "OPTIONS") {

ctx.status = 204

requestFlag = false

} else {

requestFlag = true

}

ctx.set("Access-Control-Allow-Origin", "*");

ctx.set("Access-Control-Allow-Credentials", true);

ctx.set("Access-Control-Request-Method", "*");

ctx.set(

"Access-Control-Allow-Headers",

"X-Requested-With,Content-Type,Accept,Origin"

);

ctx.set("Access-Control-Max-Age", 86400);

// 根据具体情况进行修改

ctx.set("Access-Control-Expose-Headers", "With-Requested-Key");

await next();

if(requestFlag) {

ctx.body = body

body = ''

}

});

app.use(async (ctx, next) => {

if (!requestFlag) return

await p4r(ctx)

});

function p4r(ctx) {

return new Promise((res, rej) => {

const proxyRequest = http.request({

host: '127.0.0.1',

port: 9527,

path: ctx.url,

method: ctx.method,

headers: ctx.header

},

serverResponse => {

serverResponse.on('data', chunk => {

body += chunk

})

serverResponse.on('end', () => {

res(body)

})

}

proxyRequest.end()

})

}

app.on('error', (err, ctx) => {

console.error('server error', err, ctx)

});

app.listen(1005, (err) => {

if (err) console.log('服务器启动失败');

else console.log('proxy server 1005 running --> ✨✨✨');

})

//targetServer.js

const data = {val : 123}

// 配合代理服务器的post路由

router.post('/api/getMessage', (ctx) => {

ctx.body = JSON.stringify(data)

})

// 定义好路由组件的内容后进行路由注册

app.use(router.routes())

app.on('error', (err, ctx) => {

console.error('server error', err, ctx)

});

app.listen(9527, (err) => {

if (err) console.log('服务器启动失败');

else console.log('服务器启动成功');

})

后端代码主要分两部分:

代理服务器(proxyServer),代理服务器设置CORS时不限制通行,在koa2框架中,通过中间件向目标服务器发送请求,当接收到对应数据后,再响应给浏览器

目标服务器(targetServer),目标服务器不需要做太复杂的配置,案例中只是将数据传递给请求方

Ok,我们通过这个案例,明确代理服务器的具体效果,浏览器向目标服务器直接请求资源,仍然会受到同源策略的影响,但通过代理服务器向目标服务器请求资源时,却没这种限制。

那在实际项目中,我们可以通过脚手架或打包工具的配置文件,简洁方便地设置代理服务器,无需自己手写服务器代码,拿vue的脚手架为例:

devServer:{

proxy:{

'api':{

target:'127.0.0.1:9527', //目标服务器地址

changeOrigin: true, // 是否允许跨域

pathRewrite: { //是否重写接口

'api':'',

}

}

}

}

在配置的时候,可以通过框架的脚手架,或者打包工具确定配置文件,例如一些熟悉的字眼:vue.config.jswebpack.config.jspackage.json(react),更准确的做法就是直接去对应工具的官方文档查阅代理服务器的配置介绍。

总结

对于跨域,许多同学都答得上来跨域是怎么产生的,以及解决跨域的方案。但在交流过程中,就总是一两句就讲完让我觉得有点可惜。

前后端交互,或者应该说网络协议,一直都是个大课题,是只要涉及这一块的程序员,都应该而且有必要学习的内容。类似上文中CORS配置时前后端要如何配合,以及使用CORS时前端的注意点都少有人提及。后端是主要的配置方,但不代表这一块的知识限于只需后端理解。

了解知识点的本质,才能尽量保证在不同的项目场景实施对应方案。



Tags:跨域   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,不构成投资建议。投资者据此操作,风险自担。如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除。
▌相关推荐
跨域,对于正在学习或者已经就业的前端同学而言,就是老朋友。只要涉及“请求”“前后端交互”“开发阶段”等关键字,都避不开跨域。同时它也是面试中最常出现的考点之一,面试官可...【详细内容】
2023-05-06  Tags: 跨域  点击:(0)  评论:(0)  加入收藏
现在的web项目,很多都是前后端分离,特别容易出现跨域问题那么什么是跨域问题呢?本篇文章带你彻底从本质上弄明白什么是跨域问题以及如何解决一 跨域有什么现象?我们先看一下现象...【详细内容】
2022-10-19  Tags: 跨域  点击:(202)  评论:(0)  加入收藏
Spring Boot + Vue 这一对技术栈目前看来可以说是非常的火热,关于 Spring Boot 松哥已经写过多篇教程,公号后台回复 666 可以获取 PDF 链接。前后端分离的文章也写过好几篇了,...【详细内容】
2022-09-06  Tags: 跨域  点击:(152)  评论:(0)  加入收藏
为什么有了跨域这个东西世上本没有路,走的人多了也就有了路。 跨域这算是这么一回事。 在 Web 的世界上本没有跨域这个东西,但架不住坏人越来越多,所以后来就有了跨域。何出此...【详细内容】
2022-08-09  Tags: 跨域  点击:(158)  评论:(0)  加入收藏
什么是跨域?浏览器有一个安全机制叫同源策略。 同源就是指协议、域名、端口都一样,如果任意一项不一致就是不同源。简单点说就是,你的网页URL和你调用的接口URL不是一个地方的,...【详细内容】
2022-06-30  Tags: 跨域  点击:(154)  评论:(0)  加入收藏
1. 第一种import org.springframework.context.annotation.Configuration;import org.springframework.web.servlet.config.annotation.CorsRegistry;import org.springfram...【详细内容】
2022-03-02  Tags: 跨域  点击:(235)  评论:(0)  加入收藏
许多同学对BGP/MPLS IP VPN跨域网络中的OptionA、OptionB和OptionC方式,特别是的OptionC方式的基本工作原理,及它们之间的主要区别不清楚。下面就给大家简单总结一下:1. 跨域VP...【详细内容】
2022-01-06  Tags: 跨域  点击:(1461)  评论:(0)  加入收藏
问题后端已经配置好了跨域,前端本地搭建vue-cli测试环境的时候如何解决跨域?(前提进行了基本的axios封装)分析这个时候后端API是一个明确的外网环境(使用外网IP或固定域名访问),...【详细内容】
2021-11-03  Tags: 跨域  点击:(488)  评论:(0)  加入收藏
浏览器的同源策略跨域的根本原因就是因为浏览器的同源策略,这是浏览器出于安全性考虑做出的限制,所谓同源是指:域名、协议、端口相同。比如在互联网上有两个资源(网页或者请求等...【详细内容】
2021-09-17  Tags: 跨域  点击:(289)  评论:(0)  加入收藏
前言难以置信,我居然被跨域问题折磨了一上午。相信很多程序员都遇到过跨域问题,当然,解决方案也有很多种。但我今天尝试了无数种办法,依旧没有解决。直到最后我媳妇儿给了我个提...【详细内容】
2021-09-16  Tags: 跨域  点击:(595)  评论:(0)  加入收藏
▌简易百科推荐
我们都知道,磁盘IO以块为单位读取数据,如果你所需要的数据都存储在一个块呢,一次IO即可返回。如果跨越多个块,只要你的块是连续的,类似MYSQl,基于预读机制,一次读取多个块的数据。...【详细内容】
2023-05-16  一个即将退役的码农  今日头条  Tags:ArrayList   点击:(2)  评论:(0)  加入收藏
最近这段时间小编陆续收到粉丝们的私信,提到的最多的问题就是有没有非常优秀的开源项目推荐,有没有AI相关的开源项目推荐,有没有的ChatGPT开源项目推荐等等。说句话实话,优化开...【详细内容】
2023-05-16  Echa攻城狮  今日头条  Tags:Github   点击:(4)  评论:(0)  加入收藏
作者 | Robin Guldener策划 | 言征OAuth 是一个标准协议。基本上你可以想象的每种编程语言都有 OAuth 2.0 的客户端库。但有了客户端库,却并不意味着万事大吉,如果你能够在大...【详细内容】
2023-05-16    51CTO  Tags:OAuth   点击:(4)  评论:(0)  加入收藏
大家好,我是前端西瓜哥。为了测试 Yjs 的协同能力,我实现了支持协同简单的 TODO 应用。支持的功能 创建房间; 新增、删除、完成、清空所有待办; 撤销重做; 显示其他用户的光标位...【详细内容】
2023-05-15  前端西瓜哥  微信公众号  Tags:React   点击:(3)  评论:(0)  加入收藏
大家好,我是哪吒。今天分享一下Redis布隆过滤器的原理和应用场景,解决缓存穿透,实现快速入门,丰富个人简历,提高面试level,给自己增加一点谈资,秒变面试小达人,BAT不是梦。一、缓存...【详细内容】
2023-05-15  哪吒编程  微信公众号  Tags:缓存穿透   点击:(5)  评论:(0)  加入收藏
新智元报道编辑:桃子【新智元导读】人人动嘴编程的时代,这就来了。前段时间,最大开源社区Hugging Face发布了AI聊天机器人HuggingChat,瞬间引爆全网。网友纷纷表示,如果ChatGPT是...【详细内容】
2023-05-15    新智元   Tags:Copilot   点击:(3)  评论:(0)  加入收藏
作者:vivo 互联网服务器团队- Yuan Jian Wei从内部需求出发,我们基于TiKV设计了一款兼容Redis的KV存储。基于TiKV的数据存储机制,对于窗口数据的处理以及过期数据的GC问题却成...【详细内容】
2023-05-15  OSC开源社区    Tags:KV存储   点击:(0)  评论:(0)  加入收藏
对,你没看错, 本文就是教你怎么写出让同事无法维护的代码! anyway,just a joke, don&#39;t try it 01. 程序命名 容易输入的变量名。比如:Fred,asdf 单字母的变量名。比如:a,b,c,...【详细内容】
2023-05-15  是蜃楼啊  今日头条  Tags:代码   点击:(2)  评论:(0)  加入收藏
缓存,消息队列,分库分表是高并发解决方案三剑客。缓存之所以能够让系统“更快”,本质上做到了如下两点: 减小 CPU 消耗 将原来需要实时计算的内容提前算好、把一些公用的数据进...【详细内容】
2023-05-08  勇哥java实战分享    Tags:缓存   点击:(13)  评论:(0)  加入收藏
注:全民开发的英文是Citizen Development,由咨询公司Gartner在2010年提出的概念,指非专业开发人员使用低代码或无代码平台创建应用程序,无需IT部门的支持,旨在提高生产力并降低开...【详细内容】
2023-05-08  草料二维码    Tags:AI   点击:(16)  评论:(0)  加入收藏
站内最新
站内热门
站内头条