Lightning Web 安全性入门
学习目标
完成本单元后,您将能够:
- 描述 Lightning Web 安全性。
- 列出 Lightning Web 安全性的好处。
Lightning Web 安全性是什么?
当管理员和开发人员向他们的组织添加新特性和功能时,组织安全是重中之重。预建组件(来自 Salesforce 或 AppExchange)和自定义组件都可能带来风险,从而使组织面临危险代码的威胁。
但安全性不应以牺牲性能或限制功能为代价。因此 Salesforce 创建了 Lightning Web 安全性 (LWS) 来帮助您确保组织的安全。LWS 通过新的 Lightning 组件用例添加了更强大的功能。但在了解更多有关 LWS 的信息之前,让我们先简要了解一下它的前身 Lightning Locker。
Lightning Locker
如果您已经在使用 Lightning 组件,那么您对 Lightning Locker 应该很熟悉。Lightning Locker 通过将 Lightning 组件命名空间隔离在它们自己的容器中并执行编码最佳实践,一直是保持 Lightning Web 组件和 Aura 组件安全的标准。例如,一个名为 c-editor
的组件是来自 c 命名空间,并且与 ltngmu
命名空间中的组件隔离。
Lightning Locker 不会立即消失。默认情况下,对于没有自定义 Lightning Web 组件或 Aura 组件的组织来说,Lightning Web 组件的 LWS (GA) 和 LWS for Aura(Beta 版)为启用状态。这一启用状态将有利于继续逐步推出 Spring '22 中宣布的 LWS 架构。Lightning Web 安全性是组件安全和性能的未来,因此您越早迁移到 LWS,您的组织就会越安全、越迅速。
新一代——Lightning Web 安全性
Lightning Web 安全性是 Lightning 组件的新成员。如果您使用 Lightning 组件,那您就知道您的 Salesforce 页面可以包含任意数量的其他公司的组件。您的自定义组件与 Salesforce 创建的组件以及您开发或使用的 AppExchange 上的应用程序混在一起。
您的环境中有着来自不同来源的众多组件,包括从静态资源加载的第三方库,这为潜在威胁打开了大门。组件中的恶意代码可以访问窗口、文档或元素等全局对象,获取它们的资源或数据,并对您的组织造成严重破坏。
通过 JavaScript Sandboxing 实现安全性
Lightning Web 安全性中的架构通过将每个组件隔离在专用于其命名空间的 JavaScript Sandbox 中,从而在您的环境中发挥作用。来自一个组件的危险代码无法访问其命名空间之外的任何其他组件的资源。
Lightning Web 安全性用例
虽然 Lightning Locker 和 Lightning Web 安全性都会阻止或修改不安全 API 的行为,但 LWS 还提供了以下额外用途来增强性能和安全性。
跨命名空间组件使用
Lightning Web 组件可以从不同的命名空间导入组件或模块,并通过组合或扩展来使用它们。组件被透明地隔离在它们自己的命名空间的 JavaScript Sandbox 中。您甚至都不会知道发生了隔离。
与全局对象的交互
Lightning Locker 需要安全包装来隔离组件,限制了性能并禁止使用某些第三方库。Lightning Web 安全性通过阻止或修改检测到不安全代码的组件的行为,消除了对安全包装的需求。它在代码所在的 Sandbox 中执行此操作,因此不会造成麻烦。这使您可以更自由、更灵活地在组件中使用第三方库。
访问 iFrame 内容和身份
Lightning Web 安全性允许 Lightning Web 组件访问 iframe 元素中的内容,因此您可以使用被 Lightning Locker 阻止的其他 Web 开发功能。
性能更强
无需安全包装,命名空间 JavaScript Sandbox 中的代码执行速度更快。
更好地支持第三方 JavaScript 库
在 LWS 中,库可以执行诸如操纵全局对象之类的操作,因为它们在自己的命名空间 JavaScript Sandbox 中运行。这些对全局对象的更改不会影响其他命名空间中的组件。
Lightning Web 安全性随着 JavaScript 的演进而发展
LWS 以最新 TC39 标准为蓝本,该标准会随着浏览器平台的演进而发展,这意味着它不会因技术变化而过时。
在下一个单元中,我们将深入探讨 Lightning Web 安全性的工作原理、如何判断您是否有组件会受 LWS 影响,以及如何在您的组织中启用 LWS。