小部件 - Iframe 与 JavaScript
我必须开发一个可供第三方网站使用的小部件.这不是要部署在社交网站中的应用程序.我可以给站点人员一个链接，用作 iframe 的 src，或者我可以将其开发为 JavaScript 请求.
I have to develop a widget that will be used by a third party site. This is not an application to be deployed in a social networking site. I can give the site guys a link to be used as the src of an iframe or I can develop it as a JavaScript request.
谁能告诉我这两种方法(IFrame 与 JS)之间的权衡?
Can someone please tell me the trade offs between the 2 approaches(IFrame versus JS)?
推荐答案
我在搜索同样的问题，发现这篇有趣的文章:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
I was searching about the same question and I found this interesting article:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
小部件是可以轻松添加到任何网络的小型网络应用程序页.它们有时被称为小工具，广泛用于种植网页、博客、社交网站、个性化主页等的数量如 iGoogle、我的 Yahoo、netvibes 等.在这个博客中，我使用了几个小部件，例如右侧的 RSS 计数器，它显示有多少用户订阅了这个博客(别担心，它会增长，这是一个新博客 ;-) ).小部件很棒，因为它们很小即使是非程序员也可以使用的可重用功能丰富他们的网站.
Widgets are small web applications that can easily be added to any web page. They are sometimes called Gadgets and are vastly used in growing number of web pages, blogs, social sites, personalized home pages such as iGoogle, my Yahoo, netvibes etc. In this blog I use several widgets, such as the RSS counter to the right which displays how many users are subscribed to this blog (don’t worry, it’ll grow, that’s a new blog ;-) ). Widgets are great in the sense that they are small reusable piece of functionality that even non-programmers can utilize to enrich their site.
随着时间的推移，我已经编写了几个这样的小部件，两个原始"小部件可以嵌入到任何网站以及 iGoogle 小工具中更有条理，worpress*，打字板和博客小部件，所以我很高兴分享我的经验.
I’ve written several such widgets over the time both "raw" widgets that can get embedded in any site as well as iGoogle gadgets which are more structured, worpress*, typepad and blogger widgets, so I’m happy to share my experience.
作为小部件作者，对于在客户端运行的小部件(简单可嵌入的 HTML 代码)您可以选择编写您的小部件在 iframe 内或简单地内联页面并使其成为 dom 的一部分的托管页面.帖子的其余部分讨论了利弊两种方法.
As a widget author, for widgets that run on the client side (simple embeddable HTML code) you have the choice of writing your widget inside an iframe or simply inline the page and make it part of the dom of the hosting page. The rest of the post discusses the pros and cons of both methods.
它在技术上是如何完成的?如何使用 iframe 或如何实现内联小部件?
How is it technically done? How to use an iframe or how to implement an inline widget?
iframe 更容易实现.下面的例子呈现一个简单的 iframe 小部件:http://my-great-widget.com/widgwt' width="100" height="100"边框='0'>
Iframes are somewhat easier to implement. The following example renders a simple iframe widget: http://my-great-widget.com/widgwt' width="100" height="100" frameborder='0'>
frameborder='0' 用于确保 ifrmae 没有边框所以它在页面上看起来更自然.这http://my-great-widget.com/widget 负责提供小部件内容为完整的 HTML 页面.
frameborder=’0′ is used to make sure the ifrmae doesn’t have a border so it looks more natural on the page. The http://my-great-widget.com/widget is responsible of serving the widget content as a complete HTML page.
内联小工具可能如下所示:
Inline gadgets might look like this:
function createMyWidgetHtml() { return "Hello world of widgets";}document.getElementById('myWidget').innerHTML = createMyWidgetHtml();如您所见，它负责的函数 createMyWidgetHtml()创建实际的小部件内容，不一定要与服务器交谈以执行此操作.在 iframe 示例中，必须有一个服务器.在内联示例中，不需要服务器，虽然如果需要，可以从服务器获取数据，这实际上是一种非常常见的情况，小部件通常会调用服务器端代码.使用内联方法服务器端代码通过以下方式调用按需 javascript.
function createMyWidgetHtml() { return "Hello world of widgets"; } document.getElementById('myWidget').innerHTML = createMyWidgetHtml(); As you can see, the function createMyWidgetHtml() it responsible for creating the actual widget content and does not necessarily have to talk to a server to do that. In the iframe example there must be a server. In the inline example there does not need to be a server, although if needed, it’s possible to get data from the server, which actually is a very common case, widgets typically do call server side code. Using the inline method server side code is invoked by means of on-demmand javascript.
所以，总而言之，在 iframe 案例中，我们只需放置一个 iframe HTML代码并将 iframe 的源指向一个服务器位置实际上提供小部件的内容.在内联的情况下，我们使用 javascript 在本地创建内容.你当然可以结合iframe 与 javascript 的使用以及内联方法的使用使用服务器端调用，您不受此限制，但路径差异化开始.
So, to summarize, in the iframe case we simply place an iframe HTML code and point the source of the iframe to a sever location which actually serves the content of the widget. In the inline case we create the content locally using javascript. You may of course combine usage of iframe with javascript as well as use of the inline method with server side calls, you’re not restricted by that, but the paths start differentially.
那么有什么大不了的?有什么不同?有几种重要的区别，所以这里开始有趣的部分发帖.
So what is the big deal? What’s the difference? There are several important differences, so here starts the interesting part of the post.
安全.iFrame 小部件更安全.
Security. iFrame widgets are more secure.
小工具会带来哪些风险，哪些人实际上面临风险?这网站的用户和网站的声誉面临风险.
What risks do gadgets impose and who’s actually being put at risk? The user of the site and the site’s reputation are at risk.
对于内联小工具，浏览器认为小工具的来源代码代码来自托管站点.假设您正在浏览你最喜欢的邮件应用程序 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 因失去声誉而受到伤害.
With inline gadgets the browser thinks that the source of the gadget code code comes from the hosting site. Let’s assume you’re browsing your favorite mail application http://my-wonderful-email.com and this mail application has installed a widget that displays a clock from http://great-clock-widgets.com/. If that widgets is implemented as an inline widget the browser thinks that the widget’s code originated at my-wonderful-email.com and not at great-clock-widgets.com and so it’ll let the widget’s code ultimately get access to the cookies owned by my-wonderful-email.com and the widget’s evil author will steal your email. It’s important to realize that browsers don’t care about where the javascript file is hosted; as long as the code runs on the same frame, the browser regards all code as originationg at the frame’s domain. So, you as a user get hurt by losing control over your email account and my-wonderful-email gets hurt by losing its reputation.
如果在 iframe 中实现了相同的时钟并且iframe 源不同于页面源(即常见情况，例如页面来源是 my-wonderful-email.com 和小工具来源是 great-clock-widgets.com) 那么浏览器不会允许时钟小部件访问页面 cookie，也不允许访问托管文档的任何其他部分，包括主机页面 dom.这样更安全.事实上，私人住宅像 iGoogle 这样的页面甚至不允许内联小工具，只有 iframe允许使用小工具.(仅在极少数情况下允许使用内联小工具，只有经过 iGoogle 团队彻底检查以确保他们不是恶意的)
If the same clock would have gotten implemented inside an iframe and the iframe source is different from the page source (which is the common case, e.g. the page source is my-wonderful-email.com and the gadget source is great-clock-widgets.com) then the browser would not allow the clock widgets access to the page cookies, nor will it allow access to any other part of the hosting document, including the host page dom. That’s way more secure. As a matter of fact, personal home pages such as iGoogle don’t even allow inline gadgets, only iframe gadgets are allowed. (inline gadgets are allowed only in rare cases, only after thorough inspection by the iGoogle team to make sure they’re not malicious)
总而言之，iframe 小部件更加安全.然而，他们也是在功能上更加有限.接下来我们将讨论你失去了什么功能.
To sum up, iframe widgets are way more secure. However, they are also way more limited in functionality. Next we’ll discuss what you lose in functionality.
外观 在外观战斗内联小工具中(通常是**)赢.关于它们的好处是它们可以看起来像页面的一部分.他们可以从页面继承 CSS 样式，包括字体、颜色、文本大小等.Iframe、OTHO 必须从地面，所以它们很难很好地融入页面.
Look and feel In the look and feel battle inline gadgets (usually**) win. The nice thing about them is that they can be made to look as part of the page. They can inherit CSS styles from the page, including fonts, colors, text size etc. Iframes, OTHO must define their CSS from the grounds up so it’s pretty hard for them to blend nicely in the page.
但更重要的是 iframe 必须声明它们的大小将是.将 iframe 添加到页面时，您必须包括一个宽度和一个高度属性，如果你不这样做，浏览器将使用一些默认设置.现在，如果你的小部件是一个时钟小部件很容易 b/c 你知道你想要它的大小，但是在很多情况下，您事先不知道您的小部件有多少空间要去拿.例如，如果您正在创作一个显示某种列表，你不知道这个列表会持续多久是或每个项目的宽度.通常在 HTML 中，这不是很重要，因为 HTML 是一种基于声明的语言，所以您只需要要做的就是告诉浏览器你想显示什么和浏览器将为它找出一个合理的布局，但是使用 iframe并非如此；使用 ifrmaes 浏览器要求您准确告知iframe 的大小是多少，它不会自己弄清楚.这对于想要使用 iframe 的小部件作者来说，这是一个真正的问题——如果你需要太多空间页面中会有空白，如果你指定太少页面将有滚动条，上帝禁止.
But what’s even more important is that iframes must declare what their size is going to be. When adding an iframe to a page you must include a width and a height property and if you don’t, the browser will use some default settings. Now, if your widget is a clock widget that’s easy enough b/c you know exacly what size you want it to be, but in many cases you don’t know ahead of time how much space your widget is going to take. If, for example you’re authoring a widget that displays a list of some sort and you don’t know how long this list is going to be or how wide each item is going to be. Usually in HTML this is not a big deal because HTML is a declarative based language so all you need to do is tell the browser what you want to display and the browser will figure out a reasonable layout for it, however with iframe this is not the case; with ifrmaes browsers demand that you tell it exactly what the iframe size is and it will not figure it out by itself. This is a real problem for widget authors that want to use iframes – if you require too much space the page will have voids in it and if you specify too little the page will have scrollbars in it, god forbids.
外观和感觉明智，内联获胜.但请注意，这实际上取决于您的小部件应用程序.如果你想做的只是一个时钟，你可能会得到以及 iframe.
Look and feel wise, inline wins. But note that this really depends on your widget application. If all you want to do is a clock, you may get along with an iframe just as well.
服务器端与客户端 IFrmaes 要求您指定 src URL，因此使用 iframe 实现小部件时，您必须有服务器端代码.这对某些人来说既是一个限制，也是一个令人头疼的问题(拥有服务器，域名等，处理负载，支付网络账单等)但对其他人来说，这实际上是支持 iframe b/c 的一点让您完全使用服务器端技术编写小部件，所以你可以编写很多代码，实际上几乎所有代码都使用您最喜欢的服务器端技术，无论是 asp.net、django、ror、jsp、struts、perl 或其他恐龙.当实施一个内联小工具，您会发现自己越来越多地练习您的javascript忍者.
Server side vs. Client side IFrmaes require you specify a src URL so when implementing a widget using an iframe you must have server side code. This could both be a limitation and a headache to some (owning a server, domain name etc, dealing with load, paying network bills etc) but to others this is actually a point in favor of iframes b/c it let’s you completely write your widgets in server side technologies, so you can write a lot of the code and actually almost all of it using your favorite server side technology whether it be asp.net, django, ror, jsp, struts , perl or other dinosaurs. When implementing an inline gadget you’ll find yourself more and more practicing your javascript Ninja.
那么决策算法是什么?小部件作者:如果小部件可以被实现为 iframe，更喜欢 iframe 只是为了保留用户的安全和信任.如果一个小部件需要内联(并且介质允许，例如不是 iGoogle 和朋友)使用内联但敢不要利用用户的信任！
What’s the decision algorithm then? Widget authors: If the widget can be implemented as an iframe, prefer an Iframe simply for preserving users security and trust. If a widget requires inlining (and the medium allows that, e.g. not iGoogle and friends) use inline but dare not exploit users trust!
小部件安装程序:在您的博客中安装小部件时，您看不到小部件上的用户安全"功能区.你怎么知道如果小部件是否安全?我可以建议两种选择:1)信任供应商 2) 阅读代码.您要么信任小部件提供者并安装它，或者你花时间阅读它的代码并确定自己是否值得信赖.现实是大多数网站所有者不费心阅读代码，甚至不知道他们给用户带来的风险，以及小部件提供商被盲目信任.在许多情况下，这不是问题，因为博客通常不会保存有关其读者的个人信息.我猜测一旦很少有高调的漏洞利用，事情就会开始改变(而且我希望它永远不会发生).
Widget installers: When installing a widget in your blog you don’t see a "safe for users" ribbon on the widgets. How can you tell if the widget is safe or not? There are two alternatives I can suggest: 1) trust the vendor 2) read the code. Either you trust the widget provider and install it anyway or you take the time to read its code and determine yourself whether it’s trustworthy or not. Reality is that most site owners don’t bother reading code or are not even aware of the risk they’re putting their users at, and so widget providers are blindly trusted. In many cases this is not an issue since blogs don’t usually hold personal information about their readers. I suspect things will start changing once there are few high profile exploits (and I hope it’ll never get to it).
用户:Usres 被蒙在鼓里.就像没有安全的用户"网站所有者安装的小部件上的功能区，没有安全使用"网站，基本上用户被蒙在鼓里，不知道，即使他们拥有技术技能，无论他们的网站是否正在使用包含小部件，无论小部件是否内联，并且他们是否是恶意的.虽然理论上训练有素的开发人员可以预先检查代码，然后在她的浏览器中运行它并丢失将她的电子邮件帐户发送给黑客，但这并不实用不应期望大量用户会这样做.海事组织这是不幸的情况，我只希望攻击者不会找到方法利用这一点并毁灭美妙的开放小部件文化在网络上.
Users: Usres are kept in the dark. Just as there are no "safe for users" ribbons on widgets site owners install, there are no "safe to use" sites and basically users are kept in the dark and have no idea, even if they have the technical skills, whether or not the site they are using contains widgets, whether the widgets are inline or not and whether they are malicious. Although in theory a trained developer can inspect the code up-front, before running it in her browser and losing her email account to a hacker, however this is not practical and there should be no expectation that users en mass will do that. IMO this is an unfortunate condition and I only hope attackers will not find a way of taking advantage of that and doom the wonderful open widget culture on the web.
小部件们快乐！
- 一些博客平台的小部件结构有些不同，它们有时可能同时具有小部件和插件与它们的功能相关，但对于讨论的问题在这里，我将愚蠢地使用术语小部件来讨论原始"类型由客户端javascript代码组成** 虽然在大多数情况下，您希望小部件从托管页面继承样式以使其看起来与其一致，但有时您实际上不希望小部件从页面继承样式，所以在这个案例 iFrames 让您可以从头开始编写 CSS.
相关文章