使用innerHTML加载iframe有什么问题吗？

发布于 2024-08-05 11:14:29 字数 762 浏览 3 评论 0原文

我的应用程序（正在开发中）使用 Safari 4.0.3 和 JavaScript 向用户展示其前端。后端是 PHP 和 SQLite。这是在 OS X 10.5.8 下。

该应用程序会不时接收 HTML 块以呈现给用户。每个块都是收到的电子邮件的正文，因此无法控制收到的 HTML 的质量。我所做的是使用innerHTML 将块推入iFrame 并让Safari 渲染它。

为此，我这样做：

window.frames["mainwindow"].window.frames["Frame1"].document.body.innerHTML = myvar;

其中 myvar 包含收到的 HTML。现在，在大多数情况下，这可以按预期工作，并且 HTML 按预期呈现。例外情况似乎是当块的标签看起来像：

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" ...

等等超过 2800 个字符时。效果就好像我上面的 JavaScript 语句没有被执行 - 我可以看到使用“开发”菜单中的 Safari 错误控制台来查看 iFrame。如果我从 SQLite 后端数据库中提取 HTML 并将其保存为 .html 文件，那么 Safari 将毫无问题地呈现它。

任何关于为什么会发生这种情况的评论，或者关于innerHTML的这种使用的评论，或者指向相同讨论的指针，将不胜感激。

原文

My app (under development) uses Safari 4.0.3 and JavaScript to present its front end to the user. The backend is PHP and SQLite. This is under OS X 10.5.8.

The app will from time to time receive chunks of HTML to present to the user. Each chunk is the body of an email received, and as such one has no control over the quality of the HTML received. What I do it use innerHTML to shove the chunk into an iFrame and let Safari render it.

To do that I do this:

window.frames["mainwindow"].window.frames["Frame1"].document.body.innerHTML = myvar;

where myvar contains the received HTML. Now, for the most part this works as desired, and the HTML is rendered as expected. The exception appears to be when the tag for the chunk looks like:

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" ...

and so on for more than 2800 chars. The effect is as if my JavaScript statement above had not been executed - I can see that using Safari's Error Console in the Develop menu to look into the iFrame. If I extract the HTML from the SQLite backend db and save it as a .html file, then Safari will render that with no trouble.

Any comments on why this might be happening, or on such use of innerHTML, or pointers to discussion of same, would be appreciated.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

放肆 2024-08-12 11:14:29

innerHTML 与编写完整的文档不同。即使您按照 Gumbo 的建议写入 outerHTML，根元素之外的某些内容也可能会造成混淆，例如文档类型。要一次编写整个文档，您必须使用老式的跨框架 document.write：

var d= window.frames["mainwindow"].window.frames["Frame1"].document;
d.open();
d.write(htmldoc);
d.close();

每个块都是收到的电子邮件的正文，因此无法控制收到的 HTML 的质量。

好吧，那么你可能会遇到安全问题。

如果您让电子邮件等不受信任的来源将 HTML 注入您的安全上下文（并且您正在安全上下文中写入的 iframe），它可以运行自己的 JavaScript，包括脚本可以到达并控制整个封闭应用程序以及同一主机名上的任何其他内容。除非您的应用程序非常琐碎，您不关心它，否则这确实是个坏消息。

如果您需要允许不受信任的 HTML，许多网络邮件服务的做法是在不同的主机名（例如子域）上提供服务，而该主机名无法访问应用程序的任何其他部分。为此，您的 iframe src 必须指向不同的主机名；您无法在两个安全上下文之间编写脚本。

innerHTML is not the same as writing a complete document. Even if you write to outerHTML as suggested by Gumbo, there are things outside the root element that can confuse it, such as doctypes. To write a whole document at once, you have to use old-school cross-frame document.write:

var d= window.frames["mainwindow"].window.frames["Frame1"].document;
d.open();
d.write(htmldoc);
d.close();

Each chunk is the body of an email received, and as such one has no control over the quality of the HTML received.

OK, you may have a security problem then.

If you let an untrusted source like an e-mail inject HTML into your security context (and an iframe you're writing to is in your security context), it can run JavaScript of its own, including scripts that reach up and control your entire enclosing application and anything else on the same hostname. Unless your application is so trivial you don't care about that, this is really bad news.

If you need to allow untrusted HTML, the way many webmail services do it is to have it served on a different hostname (eg. a subdomain) that does not have access to any other part of the application. To do this, your iframe src would have to point to the different hostname; you couldn't script between the two security contexts.

回复收藏 0 原文

~没有更多了~