小部件 - Iframe与JavaScript

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

有人可以告诉我两种方法之间的权衡(IFrame与JS)吗？

我正在搜索同样的问题,我找到了这篇有趣的文章:http:
//prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/

窗口小部件是可以轻松添加到任何网页的小型Web应用程序.它们有时被称为小工具,并且在越来越多的网页,博客,社交网站,个性化主页(如iGoogle,我的Yahoo,netvibes等)中被广泛使用.在这个博客中我使用了几个小部件,例如右边的RSS计数器显示有多少用户订阅了这个博客(不用担心,它会增长,这是一个新的博客;-)).小部件非常棒,因为它们是可重用的小功能,甚至非程序员也可以利用它来丰富自己的网站.

我已经写了几个这样的小部件,当时可以嵌入任何网站的"原始"小部件以及更结构化,worpress*,typepad和blogger小部件的iGoogle小工具,所以我很乐意分享我的经验.

作为窗口小部件作者,对于在客户端运行的窗口小部件(简单的可嵌入HTML代码),您可以选择在iframe中编写窗口小部件,或者只是内联页面并使其成为托管页面的dom的一部分.本文的其余部分讨论了两种方法的优缺点.

技术上如何完成？如何使用iframe或如何实现内联窗口小部件？

iframe更容易实现.以下示例呈现一个简单的iframe小部件:http://my-great-widget.com/widgwt'width ="100"height ="100"frameborder ='0'>

frameborder ='0'用于确保ifrmae没有边框,因此它在页面上看起来更自然.该 http://my-great-widget.com/widget负责服务Widget内容作为一个完整的HTML页面.

内嵌小工具可能如下所示:

function createMyWidgetHtml(){return"Hello world of widgets"; } document.getElementById('myWidget').innerHTML = createMyWidgetHtml(); 正如您所看到的,函数createMyWidgetHtml()负责创建实际的窗口小部件内容,并且不一定要与服务器通信来执行此操作.在iframe示例中,必须有服务器.在内联示例中,不需要是服务器,尽管如果需要,可以从服务器获取数据,这实际上是一种非常常见的情况,小部件通常会调用服务器端代码.使用内联方法服务器端代码通过on-demmand 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文件的托管位置; 只要代码在同一帧上运行,浏览器就会将所有代码视为帧的域中的originationg.因此,当用户因失去对电子邮件帐户的控制而受到伤害时,我的精彩电子邮件会因失去声誉而受到伤害.

如果在iframe中实现相同的时钟并且iframe源与页面源不同(这是常见的情况,例如页面源是my-wonderful-email.com而且小工具源是伟大的时钟小部件然后浏览器不允许时钟小部件访问页面cookie,也不允许访问托管文档的任何其他部分,包括主机页面dom.这样更安全.事实上,iGoogle等个人主页甚至不允许使用内联小工具,只允许使用iframe小工具.(只有在极少数情况下才允许使用内联小工具,只有经过iGoogle小组的彻底检查才能确保它们不是恶意的)

总而言之,iframe小部件更安全.但是,它们在功能上也受到更多限制.接下来我们将讨论您在功能上失去的东西.

外观和感觉在外观和感觉战斗内联小工具(通常**)赢.关于它们的好处是它们可以看作是页面的一部分.他们可以从页面继承CSS样式,包括字体,颜色,文本大小等.如果是iframe,OTHO必须从头开始定义他们的CSS,这样他们很难在页面中很好地融合.

但更重要的是,iframe必须声明它们的大小.向页面添加iframe时,必须包含width和height属性,如果不包含,则浏览器将使用某些默认设置.现在,如果你的小部件是一个很容易b/c的时钟小部件,你就会明白你想要它的大小,但在很多情况下你不知道你的小部件将占用多少空间.例如,如果您正在创作一个显示某种列表的窗口小部件,并且您不知道该列表的长度或每个项目的宽度.通常在HTML中这不是什么大问题,因为HTML是一种基于声明的语言,所以你需要做的就是告诉浏览器你想要显示什么,浏览器会为它找出合理的布局,但是对于iframe,这不是案件; 与ifrmaes浏览器要求你准确地告诉它iframe大小是什么,它不会自己解决它.对于想要使用iframe的小部件作者来说,这是一个真正的问题 - 如果你需要太多空间,页面中会有空白,如果你指定的页面太少,页面中会有滚动条,上帝禁止.

外观和感觉明智,内联胜利.但请注意,这实际上取决于您的小部件应用程序.如果您只想做一个时钟,那么您也可以使用iframe.

服务器端与客户端IFrmaes要求您指定src URL,因此在使用iframe实现窗口小部件时,您必须具有服务器端代码.这可能是一些限制和一些头痛(拥有服务器,域名等,处理负载,支付网络账单等),但对其他人这实际上是一个支持iframes b/c的点,它让你完全写你的服务器端技术中的小部件,所以你可以使用自己喜欢的服务器端技术编写很多代码,实际上几乎所有代码都是asp.net,django,ror,jsp,struts,perl或其他恐龙.实施内联小工具时,您会发现自己越来越多地练习javascript Ninja.

那么决策算法是什么？窗口小部件作者:如果窗口小部件可以实现为iframe,则更喜欢仅用于保留用户安全性和信任的iframe.如果一个小部件需要内联(并且媒体允许,例如不是iGoogle和朋友)使用内联但不敢利用用户信任!

窗口小部件安装程序:在博客中安装窗口小部件时,您在窗口小部件上看不到"安全用户"功能区.如何判断小部件是否安全？我可以建议两种方法:1)信任供应商2)阅读代码.您可以信任小部件提供程序并安装它,或者您花时间阅读其代码并确定自己是否值得信赖.现实是,大多数网站所有者不打扰阅读代码或甚至不知道他们将用户带入的风险,因此小部件提供商是盲目信任的.在许多情况下,这不是问题,因为博客通常不会保存有关其读者的个人信息.我怀疑一旦很少有高调的漏洞利用,事情就会开始改变(我希望它永远不会得到它).

用户:Usres一直处于黑暗中.正如网站所有者安装的小部件上没有"安全的用户"色带一样,没有"安全使用"的网站,基本上用户被置于黑暗中并且不知道,即使他们具备技术技能,无论是否具备他们使用的网站包含小部件,小部件是否内联以及它们是否是恶意的.虽然理论上受过训练的开发人员可以预先检查代码,然后在浏览器中运行代码并将她的电子邮件帐户丢给黑客,但这并不实际,并且不应期望用户能够做到这一点.国际海事组织这是一个不幸的条件,我只希望攻击者不会找到利用这一点的方式,并在网络上毁灭美妙的开放小部件文化.

快乐的小工具人!

一些博客平台对于小部件有一些不同的结构,它们有时可能同时具有可能与其功能相关的小部件和插件,但是对于此处的讨论,我将使用术语小部件来讨论"原始"类型.由客户端javascript代码组成**尽管在大多数情况下你需要小部件从托管页面继承样式以使它们看起来与它一致,但有时你实际上不希望小部件从页面继承样式,所以在在这种情况下,iFrames可以让您从头开始创建CSS.

为什么不两个都做？

我更喜欢为第三方网站提供如下脚本:

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

document.writeln('');

更新:

使用指向服务器上的网址的iframe的一个缺点是,如果有人点击指向您服务器的服务器的网址,则不会生成"真正的"反向链接.

我相信很多开发者/网站所有者都会喜欢Javascript解决方案,他们可以根据自己的需求而不是使用iframe.如果我要包含来自第三方的组件,我宁愿通过Javascript来做,因为我会有更多的控制权.

就易用性而言,两者在简单性上相似,因此没有真正的权衡.

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