小部件 - iframe 与 JavaScript

Question

我必须开发一个可供第三方网站使用的小部件。这不是要部署在社交网站中的应用程序。我可以给站点人员一个链接，用作 iframe 的 src，或者我可以将其开发为 JavaScript 请求。

谁能告诉我这两种方法（IFrame 与 JS）之间的权衡？

Answer 1

我在搜索同样的问题，发现这篇有趣的文章：
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/

小部件是可以轻松添加到任何网络的小型网络应用程序 页。它们有时被称为小工具，广泛用于种植 网页、博客、社交网站、个性化主页等的数量 如 iGoogle、我的 Yahoo、netvibes 等。在这个博客中，我使用了几个 小部件，例如右侧的 RSS 计数器，它显示有多少 用户订阅了这个博客（别担心，它会增长，这是一个 新博客 ;-) )。小部件很棒，因为它们很小 即使是非程序员也可以使用的可重用功能 丰富他们的网站。

随着时间的推移，我已经编写了几个这样的小部件，两个“原始”小部件 可以嵌入到任何网站以及 iGoogle 小工具中 更有条理，worpress*，打字板和博客小部件，所以我很高兴 分享我的经验。

作为小部件作者，对于在客户端运行的小部件（简单 可嵌入的 HTML 代码）您可以选择编写您的小部件 在 iframe 内或简单地内联页面并使其成为 dom 的一部分 的托管页面。帖子的其余部分讨论了利弊 两种方法。

它在技术上是如何完成的？如何使用 iframe 或如何实现 内联小部件？

iframe 更容易实现。下面的例子 呈现一个简单的 iframe 小部件：http://my-great-widget.com/widgwt' width="100" height="100" 边框='0'>

frameborder='0' 用于确保 ifrmae 没有边框 所以它在页面上看起来更自然。这 http://my-great-widget.com/widget 负责为小部件提供服务 内容为完整的 HTML 页面。

内联小工具可能如下所示：

function createMyWidgetHtml() { return "Hello world of widgets"; } document.getElementById('myWidget').innerHTML = createMyWidgetHtml(); 如您所见，它负责的函数 createMyWidgetHtml() 创建实际的小部件内容，不一定要 与服务器交谈以执行此操作。在 iframe 示例中，必须有一个 服务器。在内联示例中，不需要服务器， 虽然如果需要，可以从服务器获取数据，这 实际上是一种非常常见的情况，小部件通常会调用服务器端 代码。使用内联方法服务器端代码通过以下方式调用 按需 javascript。

所以，总而言之，在 iframe 案例中，我们只需放置一个 iframe HTML 代码并将 iframe 的源指向一个服务器位置 实际上提供小部件的内容。在内联的情况下，我们 使用 javascript 在本地创建内容。你当然可以结合 iframe 与 javascript 的使用以及内联方法的使用 使用服务器端调用，您不受此限制，但路径 差异化开始。

那么有什么大不了的？有什么不同？有几种 重要的区别，所以这里开始有趣的部分 发帖。

安全。 iFrame 小部件更安全。

小工具会带来哪些风险，哪些人实际上面临风险？这 网站的用户和网站的声誉面临风险。

对于内联小工具，浏览器认为小工具的来源 代码代码来自托管站点。假设您正在浏览 你最喜欢的邮件应用程序http://my-wonderful-email.com 和这个 邮件应用程序安装了一个显示时钟的小部件 http://great-clock-widgets.com/。如果该小部件被实现为 内联小部件浏览器认为小部件的代码起源于 my-wonderful-email.com 而不是 great-clock-widgets.com，所以它会 让小部件的代码最终获得对拥有的 cookie 的访问权 my-wonderful-email.com 和小部件的邪恶作者会窃取你的 电子邮件。重要的是要意识到浏览器不关心在哪里 托管 javascript 文件；只要代码运行在同一个 框架，浏览器将所有代码视为源自框架的 领域。因此，作为用户，您会因失去对电子邮件的控制权而受到伤害 帐户和 my-wonderful-email 因失去声誉而受到伤害。

如果在 iframe 中实现了相同的时钟并且 iframe 源不同于​​页面源（即 常见情况，例如页面来源是 my-wonderful-email.com 和 小工具来源是 great-clock-widgets.com) 那么浏览器不会 允许时钟小部件访问页面 cookie，也不允许 访问托管文档的任何其他部分，包括主机 页面 dom。这样更安全。事实上，私人住宅 像 iGoogle 这样的页面甚至不允许内联小工具，只有 iframe 允许使用小工具。 （仅在极少数情况下允许使用内联小工具， 只有经过 iGoogle 团队彻底检查以确保 他们不是恶意的）

总而言之，iframe 小部件更加安全。然而，他们也是 在功能上更加有限。接下来我们将讨论你失去了什么 功能。

外观 在外观战斗内联小工具中（通常是**） 赢。关于它们的好处是它们可以看起来像 页面的一部分。他们可以从页面继承 CSS 样式，包括 字体、颜色、文本大小等。Iframe、OTHO 必须从 地面，所以它们很难很好地融入 页面。

但更重要的是 iframe 必须声明它们的 大小将是。将 iframe 添加到页面时，您必须包括 一个宽度和一个高度属性，如果你不这样做，浏览器将使用 一些默认设置。现在，如果你的小部件是一个时钟小部件 很容易 b/c 你知道你想要它的大小，但是在 很多情况下，您事先不知道您的小部件有多少空间 要去拿。例如，如果您正在创作一个显示 某种列表，你不知道这个列表会持续多久 是或每个项目的宽度。通常在 HTML 中，这不是 很重要，因为 HTML 是一种基于声明的语言，所以您只需要 要做的就是告诉浏览器你想显示什么和浏览器 将为它找出一个合理的布局，但是使用 iframe 并非如此；使用 ifrmaes 浏览器要求您准确告知 iframe 的大小是多少，它不会自己弄清楚。这 对于想要使用 iframe 的小部件作者来说，这是一个真正的问题——如果你 需要太多空间页面中会有空白，如果你 指定太少页面将有滚动条，上帝禁止。

外观和感觉明智，内联获胜。但请注意，这实际上取决于 您的小部件应用程序。如果你想做的只是一个时钟，你可能会得到 以及 iframe。

服务器端与客户端 IFrmaes 要求您指定 src URL，因此 使用 iframe 实现小部件时，您必须有服务器端 代码。这对某些人来说既是一个限制，也是一个令人头疼的问题（拥有 服务器，域名等，处理负载，支付网络账单等） 但对其他人来说，这实际上是支持 iframe b/c 的一点 让您完全使用服务器端技术编写小部件， 所以你可以编写很多代码，实际上几乎所有代码都使用 您最喜欢的服务器端技术，无论是 asp.net、django、 ror、jsp、struts、perl 或其他恐龙。当实施一个 内联小工具，您会发现自己越来越多地练习您的 javascript忍者。

那么决策算法是什么？小部件作者：如果小部件可以 被实现为 iframe，更喜欢 iframe 只是为了保留 用户的安全和信任。如果一个小部件需要内联（并且 介质允许，例如不是 iGoogle 和朋友）使用内联但敢 不要利用用户的信任！

小部件安装程序：在您的博客中安装小部件时，您看不到 小部件上的“用户安全”功能区。你怎么知道如果 小部件是否安全？我可以建议两种选择：1） 信任供应商 2) 阅读代码。您要么信任小部件 提供者并安装它，或者你花时间阅读它的代码 并确定自己是否值得信赖。现实是 大多数网站所有者不费心阅读代码，甚至不知道 他们给用户带来的风险，以及小部件提供商 被盲目信任。在许多情况下，这不是问题，因为博客 通常不会保存有关其读者的个人信息。我猜测 一旦很少有高调的漏洞利用，事情就会开始改变 （而且我希望它永远不会发生）。

用户：Usres 被蒙在鼓里。就像没有“安全的 用户”网站所有者安装的小部件上的功能区，没有“安全 使用”网站，基本上用户被蒙在鼓里，不知道， 即使他们拥有技术技能，无论他们的网站是否 正在使用包含小部件，无论小部件是否内联，并且 他们是否是恶意的。虽然理论上训练有素的开发人员可以 预先检查代码，然后在她的浏览器中运行它并丢失 将她的电子邮件帐户发送给黑客，但这并不实用 不应期望大量用户会这样做。海事组织这是 不幸的情况，我只希望攻击者不会找到方法 利用这一点并毁灭美妙的开放小部件文化 在网络上。

小部件们快乐！

• 一些博客平台的小部件结构有些不同，有时它们可​​能同时具有小部件和插件 与它们的功能相关，但对于讨论的问题 在这里，我将愚蠢地使用术语小部件来讨论“原始”类型 由客户端javascript代码组成 ** 尽管在大多数情况下，您希望小部件从托管页面继承样式以使其看起来与其一致，但有时您 实际上不希望小部件从页面继承样式，所以在 这个案例 iFrame 让您可以从头开始编写 CSS。

Answer 2

为什么不两者都做？

我更喜欢向第三方网站提供如下脚本：

 <script type="text/javascript" src="urlToYourScript"></script>

您服务器上的文件如下所示：

document.writeln('<iframe src="pathToYourWidget" 
name="MagicIframe" width="300" height="600" align="left" scrolling="no" 
marginheight="0" marginwidth="0" frameborder="0"></iframe>');

更新：

使用指向服务器上 url 的 iframe 的一个缺点是，如果有人从您的服务器上点击指向您服务器的 url，您不会生成“真实”反向链接。

Answer 3

我敢肯定，许多开发人员/网站所有者会喜欢他们可以根据自己的需要设计样式的 Javascript 解决方案，而不是使用 iframe。如果我要包含来自第三方的组件，我宁愿通过 Javascript 来实现，因为我会拥有更多的控制权。

就易用性而言，两者在简单性方面相似，因此没有真正的权衡。

另一种想法是，确保您获得托管此证书的任何域的 SSL 证书，并在页面通过 SSL 提供时相应地写出包含语句。如果您的网站所有者有使用 SSL 的理由，他们肯定会喜欢这一点，因为 Firefox 和其他浏览器会在提供混合安全/不安全内容的页面时抱怨。

Answer 4

如果小部件可以嵌入到 iframe 中，则托管网站的前端性能会更好，因为 iframe 不会阻止内容下载。然而，正如其他人所评论的那样，使用 iframe 还存在其他缺点。

如果你用javascript实现，请在开发时考虑frontend performance best practices。特别是，您应该查看Non blocking javascript loading。谷歌分析和其他第 3 方小部件提供商支持这种加载方法。如果您可以在页面底部加载 javascript，也会有所帮助。

Answer 5

很高兴知道它不会部署在社交网站中......只会留下网络的其余部分;-)

什么最有用取决于您的小部件。 IFrame 和 javascript 通常用于完全不同的目的，并且可以混合使用（即 iframe 中的 javascript，或创建 iframe 的 javascript）。

• IFrame 出现大小问题；如果它应该完全适合页面，您是否知道它在所有浏览器上呈现相同，数据不会溢出它的容器等？
• IFrame 很简单。它们可以是简单的静态 HTML 页面。
• 使用 IFrame 时，您可以非常清楚地公开您的小部件。
• 但话又说回来，为什么不让您的第三方网站在给定的 url 中简单地包含 HMTL？然后可以在需要时/如果需要，扩展 HTML 以包含 javascript。
• 纯 Javascript 允许更大的灵活性，但代价是一些复杂性。

Answer 6

iframe 的一大优点：所有 CSS 和 JS 都与主机页面分离，因此您现有的 CSS 可以正常工作。 （如果您希望主机站点对您的内容进行样式化以适应，那当然是减号。）

iframe 的最大缺点：它们具有固定的宽度和高度，如果您的内容较大，则会出现滚动条。