常见的跨域场景同源策略(-建站建官网)

跨域请求为什么会出现在前端开发中?还有一类情况是在前后端分离的项目中,前端后端分属于不同的服务跨域问题在采用这种架构的时候就存在。的一种使用模式,可用于解决主流浏览器的跨域数据访问问题,在早两三年前端解决跨域问题中经常出现这类解决方案。的方式,前端编码与正常非跨域请求没有什么不同。的方案;而公司前后端分离的项目中更多是采用反向代理的方案。

前言

B站可以搜索到本文视频内容,视频内容有完整的分析演示

前端跨域请求及解决方案

在BS架构项目和前端开发编码过程中可能会遇到跨域问题,由于现代Web开发中很多项目都使用前端,跨域问题再次成为前端开发和后端分离进行分工合作的过程中会有问题。曾经有一段时间,它是许多跨域问题的解决方案。在我个人的印象中,有一段时间公司专注于为SEO搭建官网。那时候很多开发者都会在前端粘贴一个脚本来监控对网站的请求。那时,跨领域的问题开始进入我的个人视野。后来随着Vue的兴起,加上前端开发改革之风,前后端分离的开发方式,让跨域问题成为需要再次面对的问题。

所谓跨域问题,其实是浏览器一个非常核心的安全策略。解决这个问题的方法有很多,每种方法都有不同的使用场景。项目中用到了几种解决方案,这里总结一下

什么是跨域请求

在前端开发和编码过程中,常见的html标签如a、form、img、、link、ajax操作可以指向一个资源地址或者发起一个资源请求,那么这里所说的请求是同源请求还是跨域请求。

所谓跨域请求是指:当前发起请求的域与请求指向的资源所在域不一致(这里的所有域都是协议、域名和端口的集合号,同一个域就是协议、域名和端口号。都是一样的,有区别的就是跨域)。

常见的跨域场景包括:

前端跨域请求及解决方案

常见的跨域场景

同源策略(same-)

同源策略是由 .它是浏览器最基本、最核心的安全功能。如果缺少同源策略,将会影响浏览器的正常功能。可以说,网络是建立在同源策略的基础上的,浏览器是同源策略的实现。

同源策略是浏览器保护本地数据不被代码获取的数据污染的行为。所以截取的是客户端发送请求后收到的数据,即请求发送,服务器响应,但浏览器无法接收和执行。在现代浏览器中,违反同源策略的跨域请求会直接在控制台报错。

控制台错误信息

同源策略的具体表现:

为什么会有这些限制

同源策略是浏览器的核心基本安全策略,是浏览器基于安全需要而施加的限制。常见的 CSRF 和 XSS 攻击与之相关。我不会在这里介绍它。有兴趣的读者可以自行搜索了解这些攻击的原理。

为什么前端开发会出现跨域请求?

既然同源策略是浏览器的核心基础安全策略,为什么我们在做前端开发,尤其是Ajax调用的时候,需要跨域请求呢?同源策略用于防御非法攻击,但不能因为非法攻击就阻止所有跨域。

在现代前端开发中,我们经常需要调用第三方服务接口(如mock、fake api)。随着专业化分工的出现,很多专业的信息服务商为前端开发者提供了各种接口。这种情况下就需要跨域请求(这些前端接口服务很多都是使用cors方法解决跨域问题,下面会详细介绍)。

还有一种情况,前后端是分离的项目,前后端属于不同的服务。采用这种架构时存在跨域问题。而现在很多项目都采用这种前后分离的方式,其中很多项目会使用反向代理来解决跨域问题。

Ajax跨域请求如何实现

这里所说的跨域请求方案主要是针对Ajax请求的

修改浏览器的安全设置(不推荐)

既然是浏览器安全策略,最简单粗暴的方法就是禁用这个策略。此操作很危险,不推荐。我这里不做具体介绍。跨域问题刚出来的时候有人用过这种方法,现在很少有人采用了。

(JSON with )是JSON的一种使用方式,可以用来解决主流浏览器的跨域数据访问问题。这样的解决方案在前两三年的跨域问题的前端解决方案中经常出现。

原理

是不是Ajax有跨域安全问题,而标签不存在这样的问题,所以有人在这个特性上做文章来寻找解决方案。

/.js

前后端分离seo怎么实现_质壁分离前后_mysql读写分离实现

remoteFunction('remote)

.html

我们都知道这种方法可以成功,所以我们进一步改进:

/.js

let data = { code: 200, msg: "data from remote"};localFunction(data);

.html

通过这一步的改造,可以发现我们本地函数的参数来自远程服务,远程.js按照业务逻辑传参调用本地函数。

所以更进一步,动态生成 .js,代码写死。我们以后台PHP语言为例:

.php

.html

这个实现方法是一个简单的实现。核心概念是利用跨域请求,通过跨域请求将业务处理逻辑的回调函数以url参数的形式发送给远程请求,通过数据库调用获取远程请求。到达前端需要的数据后,将发送的回调函数和数据参数进行组装,生成一段可执行(json)代码,这样当请求完成后,相应的业务处理函数就会执行。

它有其天生的缺陷,因为资源请求是通过 src 的 src 进行的,所以都是 GET 方法,不支持其他 POST、PUT 等方法。这种方案用的越来越少了。

跨域资源共享CORS(-)

CORS 是一个新的 W3C 标准,它添加了一组新的 HTTP 标头字段,以允许服务器声明哪些源请求有权访问哪些资源,换句话说,它允许浏览器向声明的站点发出跨域请求CORS。

该方法的主要特点是会在响应的HTTP头中添加---等信息,从而确定哪些资源站可以进行跨域请求,还有其他几个相关的HTTP头进行更精细的控制。 ,最重要的是——。每个头信息的含义可以详细搜索。

我们以构建的远程服务为例进行说明:

var express = require("express");var cors = require("cors");var app = express();//使用express的cors中间件使其支持跨域请求app.use(cors());app.get("/", function(req, res, next) { res.json({ msg: "This is CORS-enabled for all origins!" });});app.listen(3000, function() { console.log("CORS-enabled web server listening on port 80");});

对于支持CORS的服务,最具体的Ajax请求是客户端,即浏览器,会先向服务器发送请求,判断服务器是否支持跨域请求,是否合法。浏览器,浏览器通过接收到的回复信息判断服务器是否支持这个跨域请求,如果支持则发送实际的服务请求。所以这里会有两个请求。

CORS 与 .它只支持GET,有很多限制,不满足业务处理的正常流程。使用 CORS,前端编码与普通的非跨域请求没有什么不同。目前很多Fake API(模拟接口服务)、Mock(数据模拟服务)等公共服务使用CORS解决跨域问题,如json-等。

并且都使用 src 属性,没有跨域限制。这种方法也不推荐,不再详细介绍。

反向代理

既然我们不能请求跨域,那我们不用跨域就可以了。通过在请求到达服务之前部署服务并转发接口请求,这就是反向代理。前端请求可以通过一定的转发规则转发给其他服务。举个例子:

server { listen 9999 server_name localhost #将所有localhost:9099/api为开头的请求进行转发 location ^~ /api { proxy_pass http://localhost:3000; }}

通过反向代理,我们统一前后端项目通过反向代理对外提供服务,让前端看起来好像没有跨域一样。

反向代理的问题在于原来的点对点反向代理服务的配置,目前在很多前后端分离的项目中都会用到。

总结

综上所述,CORS和反向代理是目前使用最多的解决方案。这两种方案使用的场景不同,我们要根据自己的需求来选择。公共服务、Fake API、Mock 一般使用 CORS 方案;而公司的前后端项目大多采用反向代理解决方案。

免责声明:本文来自网络用户投稿,不代表本站观点和立场。如有侵权请发送邮件至tzanseo@163.com告知本站删除,本站不负任何责任及承诺。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

发表评论

登录后才能评论