触点数字孪生，揭秘它的独特魅力
1090
2023-02-07
微前端安全性（前端安全性如何预防）
本篇文章给大家谈谈微前端安全性，以及前端安全性如何预防对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
今天给各位分享微前端安全性的知识，其中也会对前端安全性如何预防进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
基座模式
通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。
自组织模式。应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。
就当前而言，基座模式实施起来比较方便，方案也是蛮多的。
注册表模式
和微服务架构相似，不论是哪种微前端方式，都需要有一个应用注册表的服务。这个应用注册表拥有每个应用及对应的入口，即路由。
它可以是一个固定值的配置文件，如 JSON 文件，又或者是一个可动态更新的配置，又或者是一种动态的服务。
作用：
应用注册。即提供新的微前端应用，向应用注册表注册功能。
应用发现。让主应用可以寻找到其它应用。
首先看一下它的用法：
https://qiankun.umijs.org/zh/guide/getting-started
微前端每个应用都拥有自己的生命周期：
bootstrap， 只会在微应用初始化的时候调用一次，下次微应用重新进入时会直接调用 mount 钩子，不会再重复触发 bootstrap。 通常我们可以在这里做一些全局变量的初始化，比如不会在 unmount 阶段被销毁的应用级别的缓存等。
Mount，应用每次进入都会调用 mount 方法，通常我们在这里触发应用的渲染方法
Unload，删除应用的生命周期
Unmount，应用每次 切出/卸载 会调用的方法，通常在这里我们会卸载微应用的应用实例
乾坤，作为一款微前端领域的知名框架，其建立在single-spa基础上。相较于single-spa，乾坤做了两件重要的事情，其一是加载资源，第二是进行资源隔离。而资源隔离又分为Js资源隔离和css资源隔离.
每个微应用对全局的影响都会局限在微应用自己的作用域内。比如 A 应用在 window 上新增了个属性 test，这个属性只能在 A 应用自己的作用域通过 window.test 获取到，主应用或者其他应用都无法拿到这个变量。
1、快照沙箱
2、支持多应用的代理沙箱
💪 HTML Entry 接入方式，让你接入微应用像使用 iframe 一样简单。
在使用 single-spa 加载微应用时，我们加载的不是微应用本身，而是微应用导出的 JS 文件，即JS Entry。
要接入一个微应用，就需要对微应用进行一系列的改造，然而 JS Entry 的问题就出在这儿，改造时对微应用的侵入行太强，而且和主应用的耦合性太强。
微应用改造一般分为三步：
l 微应用路由改造，添加一个特定的前缀
l 微应用入口改造，挂载点变更和生命周期函数导出
在js文件的入口中会导出一个对象，这个对象上有 bootstrap、mount、unmount 这三个接入 single-spa 框架必须提供的生命周期方法，其中 mount 方法规定了微应用应该怎么挂载到主应用提供的容器节点上。
l 打包工具配置更改
侵入型强其实说的就是第三点，更改打包工具的配置，使用 single-spa 接入微应用需要将微应用整个打包成一个 JS 文件，发布到静态资源服务器，然后在主应用中配置该 JS 文件的地址告诉 single-spa 去这个地址加载微应用。这就导致常见的打包优化基本上都没了，比如：按需加载、首屏资源加载优化、css 独立打包等优化措施。
项目发布以后出现了 bug ，修复之后需要更新上线，为了清除浏览器缓存带来的应用，一般文件名会带上 chunkcontent，微应用发布之后文件名都会发生变化，这时候还需要更新主应用中微应用配置，然后重新编译主应用然后发布，这套操作简直是不能忍受的。这也是 微前端框架 之 single-spa 从入门到精通 这篇文章中示例项目中微应用发布时的环境配置选择 development 的原因。
qiankun 框架为了解决 JS Entry 的问题，于是采用了 HTML Entry 的方式，让用户接入微应用就像使用 iframe 一样简单。
https://github.com/sy-l123/qiankun-demo
👉 独立应用下的 url-loader 配置：
因为 url-loader 的 options 项的属性 publicPath 属性默认是 '' ，表示相对路径，即打包出来的资源引用 url 都会加上相对路径寻找 static 静态资源入口，比如：
所有应用编译打包部署后，当主应用加载子应用，子应用加载自身的 css 文件样式时，由于 其对应的 css 文件里面的图片 url 引用是相对路径，会出现子应用的资源相对路径拼接主应用 domain 的情况，即子应用的 ../../static/img/bg_header.790a94f4.png 会在主应用的 domain 下进行资源的寻找，导致加载失败 404 的情况。
如果项目有用到第三方库，比如 element-ui ，那么就更有必要进行处理了。因为 element-ui 的字体图标是在 css 里面引入的，还有相关背景图片的引入也是在 css 里，所以需要配置 webpack 的 url-loader ，生产模式情况下直接指定资源前缀，使之成为绝对路径。
这样配置后，打包出来的 css 样式文件会变成：
资源是绝对路径，就不会出现上面子应用资源加载失败的情况。
但是，这种前端配置文件写死路径的做法灵活性并不好，比如不能做到编译一次，任意部署，因为路径写死，所以如果需要部署到其他服务器的话，就需要重新编译了。
接下来，讲的是实现灵活部署的方案。
我们在只编译打包一次前端应用的前提下，为了实现灵活部署，需要借助 nginx 来实现。
下面以 vue-cli 3 的配置为例，与 vue-cli 2 只是写法上的区别，其他都一样。
假设主应用部署地址是 192.168.2.192 ，子应用的部署地址是 192.168.2.192:7102 。
打包编译部署后，子应用的 css 文件里面的图片资源引用 url 如下：
主应用加载子应用的时候，子应用的资源拼接主应用 domian 后，子应用的 css 文件里面的图片资源加载路径 url 就会变成：
此时的关键就是要访问到子应用的资源，而不是去主应用资源目录去找。
所以我们采用 nginx 路径代理转发端口的方案，当应用访问 192.168.2.192/live 这个路径时，经过 nginx 进行路径代理转发配置，转发到子应用端口。
配置 nginx 代理规则：
此时真正访问的资源路径（子应用资源路径）是：
👋 至此，通过修改配置 url-loader 的 publicPath 以及配置 nginx 的路径代理转发，就可以实现编译打包一次，到处部署的目的。
本文目录一览：
微前端 -- 乾坤（一）
在 toB 的前端开发工作中，我们往往就会遇到如下困境：基座模式
通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。
自组织模式。应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。
就当前而言，基座模式实施起来比较方便，方案也是蛮多的。
注册表模式
和微服务架构相似，不论是哪种微前端方式，都需要有一个应用注册表的服务。这个应用注册表拥有每个应用及对应的入口，即路由。
它可以是一个固定值的配置文件，如 JSON 文件，又或者是一个可动态更新的配置，又或者是一种动态的服务。
作用：
应用注册。即提供新的微前端应用，向应用注册表注册功能。
应用发现。让主应用可以寻找到其它应用。
首先看一下它的用法：
https://qiankun.umijs.org/zh/guide/getting-started
微前端每个应用都拥有自己的生命周期：
bootstrap， 只会在微应用初始化的时候调用一次，下次微应用重新进入时会直接调用 mount 钩子，不会再重复触发 bootstrap。 通常我们可以在这里做一些全局变量的初始化，比如不会在 unmount 阶段被销毁的应用级别的缓存等。
Mount，应用每次进入都会调用 mount 方法，通常我们在这里触发应用的渲染方法
Unload，删除应用的生命周期
Unmount，应用每次 切出/卸载 会调用的方法，通常在这里我们会卸载微应用的应用实例
乾坤，作为一款微前端领域的知名框架，其建立在single-spa基础上。相较于single-spa，乾坤做了两件重要的事情，其一是加载资源，第二是进行资源隔离。而资源隔离又分为Js资源隔离和css资源隔离.
每个微应用对全局的影响都会局限在微应用自己的作用域内。比如 A 应用在 window 上新增了个属性 test，这个属性只能在 A 应用自己的作用域通过 window.test 获取到，主应用或者其他应用都无法拿到这个变量。
1、快照沙箱
2、支持多应用的代理沙箱
💪 HTML Entry 接入方式，让你接入微应用像使用 iframe 一样简单。
在使用 single-spa 加载微应用时，我们加载的不是微应用本身，而是微应用导出的 JS 文件，即JS Entry。
要接入一个微应用，就需要对微应用进行一系列的改造，然而 JS Entry 的问题就出在这儿，改造时对微应用的侵入行太强，而且和主应用的耦合性太强。
微应用改造一般分为三步：
l 微应用路由改造，添加一个特定的前缀
l 微应用入口改造，挂载点变更和生命周期函数导出
在js文件的入口中会导出一个对象，这个对象上有 bootstrap、mount、unmount 这三个接入 single-spa 框架必须提供的生命周期方法，其中 mount 方法规定了微应用应该怎么挂载到主应用提供的容器节点上。
l 打包工具配置更改
侵入型强其实说的就是第三点，更改打包工具的配置，使用 single-spa 接入微应用需要将微应用整个打包成一个 JS 文件，发布到静态资源服务器，然后在主应用中配置该 JS 文件的地址告诉 single-spa 去这个地址加载微应用。这就导致常见的打包优化基本上都没了，比如：按需加载、首屏资源加载优化、css 独立打包等优化措施。
项目发布以后出现了 bug ，修复之后需要更新上线，为了清除浏览器缓存带来的应用，一般文件名会带上 chunkcontent，微应用发布之后文件名都会发生变化，这时候还需要更新主应用中微应用配置，然后重新编译主应用然后发布，这套操作简直是不能忍受的。这也是 微前端框架 之 single-spa 从入门到精通 这篇文章中示例项目中微应用发布时的环境配置选择 development 的原因。
qiankun 框架为了解决 JS Entry 的问题，于是采用了 HTML Entry 的方式，让用户接入微应用就像使用 iframe 一样简单。
https://github.com/sy-l123/qiankun-demo
qiankun 微前端应用实践与部署（四）
一般情况下，我们对应用进行配置打包，要对图片字体等资源进行下面配置，使得资源路径正常加载。但是，在微前端模式下，子应用打包部署后，往往会出现子应用 css 文件里面引入资源路径加载失败的问题，下面就让我们来探究一下。👉 独立应用下的 url-loader 配置：
因为 url-loader 的 options 项的属性 publicPath 属性默认是 '' ，表示相对路径，即打包出来的资源引用 url 都会加上相对路径寻找 static 静态资源入口，比如：
所有应用编译打包部署后，当主应用加载子应用，子应用加载自身的 css 文件样式时，由于 其对应的 css 文件里面的图片 url 引用是相对路径，会出现子应用的资源相对路径拼接主应用 domain 的情况，即子应用的 ../../static/img/bg_header.790a94f4.png 会在主应用的 domain 下进行资源的寻找，导致加载失败 404 的情况。
如果项目有用到第三方库，比如 element-ui ，那么就更有必要进行处理了。因为 element-ui 的字体图标是在 css 里面引入的，还有相关背景图片的引入也是在 css 里，所以需要配置 webpack 的 url-loader ，生产模式情况下直接指定资源前缀，使之成为绝对路径。
这样配置后，打包出来的 css 样式文件会变成：
资源是绝对路径，就不会出现上面子应用资源加载失败的情况。
但是，这种前端配置文件写死路径的做法灵活性并不好，比如不能做到编译一次，任意部署，因为路径写死，所以如果需要部署到其他服务器的话，就需要重新编译了。
接下来，讲的是实现灵活部署的方案。
我们在只编译打包一次前端应用的前提下，为了实现灵活部署，需要借助 nginx 来实现。
下面以 vue-cli 3 的配置为例，与 vue-cli 2 只是写法上的区别，其他都一样。
假设主应用部署地址是 192.168.2.192 ，子应用的部署地址是 192.168.2.192:7102 。
打包编译部署后，子应用的 css 文件里面的图片资源引用 url 如下：
主应用加载子应用的时候，子应用的资源拼接主应用 domian 后，子应用的 css 文件里面的图片资源加载路径 url 就会变成：
此时的关键就是要访问到子应用的资源，而不是去主应用资源目录去找。
所以我们采用 nginx 路径代理转发端口的方案，当应用访问 192.168.2.192/live 这个路径时，经过 nginx 进行路径代理转发配置，转发到子应用端口。
配置 nginx 代理规则：
此时真正访问的资源路径（子应用资源路径）是：
👋 至此，通过修改配置 url-loader 的 publicPath 以及配置 nginx 的路径代理转发，就可以实现编译打包一次，到处部署的目的。
前端微服务设计
近些年，前端发展呈百家争鸣式发展，框架层出不穷，版本更是迭代不穷，难免会出现前端项目技术栈不统一、所用框架版本不统一的情况。
如若某些项目，没有新的功能加入，又能线上稳定运行，但其技术栈却用的是 vue1.0，为了将其结合到新应用中去而对其重构，成本会很高。然而，微服务可以帮我们解决这个问题。
在既不重写原有系统的基础之下，又可以抽出人力来开发新的业务。其不仅仅对于业务人员来说是一个相当吸引力的特性，对于技术人员来说，不重写旧的业务，能在一些新技术上做挑战，也是一件很有意思的事情。
除此之外，在这两三年里，移动应用出现了一种趋势，用户不想装那么多应用。而往往一家大的商业公司，会提供一系列的应用。这些应用也从某种程度上，反应了这家公司的组织架构。然而，在用户的眼里他们就是一家公司，他们就只应该有一个产品。相似的，这种趋势也在桌面 Web 出现。聚合成为了一个技术趋势，体现在前端的聚合就是微服务化架构。
理想的前端微服务化，应该是符合如下几个特点：
路由分发式微前端，即通过设置路由，将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理来实现，又或者是应用框架自带的路由来解决。
就当前而言，通过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端” 方案。但是这种方式看上去更像是多个前端应用的聚合，即我们只是将这些不同的前端应用拼凑到一起，使他们看起来像是一个完整的整体。但是，它们并不是一个完整的整体，每次用户从 A 应用到 B 应用的时候，往往需要刷新一下页面。
通常可通过 nginx 配置反向代理，来进行路由分发，从而实现前端微服务。
它适用于以下场景：
iframe 可以创建一个全新的独立的宿主环境，这意味着我们的前端应用之间可以相互独立运行。
采用 iframe 有几个重要的前提：
即何时加载、卸载应用，如何监听应用事件等。
不论是基于 Web Components 的 Angular，或者是 VirtualDOM 的 React 等，现有的前端框架都离不开基本的 HTML 元素 DOM。
那么，我们只需要：
第一个问题，创建 DOM 是一个容易解决的问题。而第二个问题，则一点儿不容易，特别是移除 DOM 和相应应用的监听。当我们拥有一个不同的技术栈时，我们就需要有针对性设计出一套这样的逻辑。现有的框架有single-spa、qiankun、mooa等
常见的方式有：
其次，采用这种方式还有一个限制，那就是：规范！ 规范！ 规范！。在采用这种方案时，我们需要：
Web Components 组件可以拥有自己独立的 Scripts 和 Styles，以及对应的用于单独部署组件的域名。然而它并没有想象中的那么美好，要直接使用纯 Web Components 来构建前端应用的难度有：
现有的微前端框架有single-spa、qiankun、mooa。其均是在前端框架之上设计通讯、加载机制来实现的。
前端开发工程师
前端开发工程师
上海研发 - 前端社招职位 ID：J5NYV
职位描述
1.负责电商和生活方向商业化相关平台与产品的开发； 2.负责设计和参与电商和生活商业化平台的前端基建、架构建设； 3.负责页面性能优化、用户关键路径分析等体验优化工作； 4.负责协同各方一起优化产品，提升电商营销的 ROI。
职位要求
1.本科及以上学历 ，1-5年工作经验； 2. JavaScript、CSS、HTML能力过硬，安全、网络、性能优化等前端技术过关； 3.熟练掌握主流 React、Vue 等框架以及其生态的使用，深入理解其原理，有能力做较深度定制； 4.至少使用过一门后端开发语言，对于全栈开发、ServerLess 等有经验； 5. 对于微前端、SSR、低代码等前端技术有使用经验，并且有自己的思考； 6. 有 2B 业务经验， 对于电商、本地生活服务有工作经验者优先； 7.能够协调不同部门，梳理项目方案，对于敏捷开发等开发模式有实战经验者优先。
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
最近发表
推荐文章
热评文章
