我们有一个包含 HTML 代码的数据库,我们正在使用 React 将其显示在网页上,但需要对其进行解析。
我最初使用html-react-parser但在代码审查后被要求使用dangerouslySetInnerHtml代替,因为它没有任何依赖项。
除了不使用 dangerouslySetInnerHtml 之外,我无法阐明使用 html-react-parser 的任何优势,但这是优势吗?如果是,为什么?它以某种方式避免了危险还是只是隐藏了?
非常感谢,
凯蒂
我们有一个包含 HTML 代码的数据库,我们正在使用 React 将其显示在网页上,但需要对其进行解析。
我最初使用html-react-parser但在代码审查后被要求使用dangerouslySetInnerHtml代替,因为它没有任何依赖项。
除了不使用 dangerouslySetInnerHtml 之外,我无法阐明使用 html-react-parser 的任何优势,但这是优势吗?如果是,为什么?它以某种方式避免了危险还是只是隐藏了?
非常感谢,
凯蒂
我最近一直在为我正在从事的无头 CMS 项目研究这个问题。据我了解:
dangerouslySetInnerHtml
在方法之外创建 DOM 元素ReactDOM.Render()
,因此它不是由 React 库动态维护的。这基本上违背了最初使用 React 的目的(显示和维护虚拟 DOM)。
不过,更令人担忧的是,它容易受到跨站点脚本 (XSS) 攻击,这也是它得名的地方。这些是网络上一种非常常见的攻击形式。你可以在这里阅读:https ://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
如果您希望应用程序不易受到攻击,则必须使用类似DOMPurify
for的清理库dangerouslySetInnerHtml
,因此无论哪种方式,您都可能有另一个依赖项。一旦你为生产编译了应用程序npm build
(https://reactjs.org/docs/code-splitting.html
就个人而言,我不会太担心一些依赖项——它们是现代网络上的现实。我一直倾向于使用html-react-parser
,但我警告说我没有调查它是否会减少 XSS 漏洞。然而,即使两者都容易受到 XSS 攻击,至少要html-react-parser
通过引入这些元素,ReactDOM.render()
这样它们就不会使 DOM 变得全都是 catty-wompus - 这听起来像是未来灾难的秘诀。