小部件 - Iframe与JavaScript [英] Widget - Iframe versus JavaScript
问题描述
我必须开发一个将由第三方网站使用的小部件。这不是要部署在社交网站中的应用程序。我可以给站点人员一个链接，用作iframe的src，或者我可以将其作为JavaScript请求开发。
有人可以告诉我两种方法之间的权衡（IFrame与JS）吗？
我正在搜索同一个问题，我发现这篇有趣的文章：
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
小部件是小型Web应用程序，可以轻松添加到任何Web
页面。他们有时被称为小工具，并广泛用于增加
的网页，博客，社交网站，个性化主页，如iGoogle，我的雅虎，netvibes等b $ b。在这个博客中我使用了几个
小部件，例如右侧的RSS计数器，显示有多少
用户订阅了这个博客（不用担心，它会增长，这是一个
新博客;-)）。小部件非常棒，因为它们是可重复使用的小型功能，甚至非程序员也可以利用
来丰富他们的网站。
I已经写了几个这样的小部件，当时原始小部件可以嵌入任何网站以及iGoogle小工具，这些小工具是
更结构化，worpress *，typepad和blogger小部件，所以我' m happy
分享我的经验。
作为一个小部件作者，对于在客户端运行的小部件（简单的
嵌入式HTML代码）你可以选择在iframe中编写小部件
，或者只是内联页面并使其成为托管页面的dom
的一部分。本文的其余部分讨论了两种方法的优缺点
。
技术上如何完成？如何使用iframe或如何实现
内联窗口小部件？
iframe更容易实现。以下示例
呈现一个简单的iframe小部件：http：//my-great-widget.com/widgwt'width =100height =100
frameborder ='0'>
frameborder ='0'用于确保ifrmae没有边框
，因此它在页面上看起来更自然。
http://my-great-widget.com/widget 负责将小部件
内容作为完整的HTML页面提供。
内联小工具可能如下所示：
function createMyWidgetHtml（）{returnHello world of widgets; }
document.getElementById（'myWidget'）。innerHTML = createMyWidgetHtml（）;
正如你所看到的，函数createMyWidgetHtml（）它负责
创建实际的小部件内容，并且不一定要
与服务器交谈来做到这一点。在iframe示例中，必须有
服务器。在内联示例中，不需要服务器，
虽然如果需要，可以从服务器获取数据，其中
实际上是一种非常常见的情况，小部件通常会调用服务器端
代码。使用内联方法服务器端代码通过
on-demmand javascript调用。
因此，总结一下，在iframe案例中我们只需放置一个iframe HTML
代码并将iframe的源指向服务器位置，
实际上为小部件的内容提供服务。在内联案例中，我们
使用javascript在本地创建内容。您当然可以将
iframe的使用与javascript以及使用内联方法
与服务器端调用结合使用，您不受此限制，但路径
以差异方式启动。 / p>
那么最重要的是什么？有什么不同？有几个
的重要差异，所以这里开始
帖子的有趣部分。
安全性。 iFrame小部件更安全。
小工具会带来什么样的风险以及实际上谁会面临风险？该网站的
用户和网站的声誉存在风险。
使用内联小工具，浏览器认为小工具的来源
代码来自托管网站。假设您正在浏览
您最喜爱的邮件应用程序 http://my-wonderful-email.com 这个
邮件应用程序安装了一个小部件，显示来自
的时钟 http：/ /great-clock-widgets.com/ 。如果这个小部件是作为
内联小部件实现的，浏览器会认为小部件的代码来自
my-wonderful-email.com，而不是来自great-clock-widgets.com，因此它将是
让小部件的代码最终可以访问
my-wonderful-email.com所拥有的cookie，小部件的邪恶作者将窃取您的
电子邮件。重要的是要意识到浏览器不关心javascript文件托管在哪里
;只要代码在相同的
帧上运行，浏览器就会将所有代码视为框架的
域中的originationg。所以，你作为一个用户因为失去对你的电子邮件
帐户的控制而受到伤害而且我的精彩电子邮件会因失去声誉而受到伤害。
如果相同iframe将在iframe中实现，
iframe源与页面源不同（这是
常见情况，例如页面源是my-wonderful-email.com和
小工具源是great-clock-widgets.com）然后浏览器不会
允许时钟小部件访问页面cookie，也不允许
访问托管文档的任何其他部分，包括主机
页面dom。这样更安全。事实上，个人住宅
页面（如iGoogle）甚至不允许使用内嵌小工具，只允许使用iframe
小工具。 （只有在极少数情况下才允许使用内嵌小工具，只有经过iGoogle小组的彻底检查才能确保
，以确保
他们不是恶意的）
总而言之，iframe小部件更安全。但是，它们在功能上的限制也是b $ b。接下来我们将讨论你在
功能中失去的东西。
外观和感觉战斗内联小工具（通常为**）
赢得。关于他们的好处是，他们可以看起来像
页面的一部分。他们可以从页面继承CSS样式，包括
字体，颜色，文本大小等等.Oframe，OTHO必须从
定义他们的CSS，因此他们很难在$ b中很好地融合$ b page。
但更重要的是，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忍者。
那么决策算法是什么？窗口小部件作者：如果窗口小部件可以将
实现为iframe，则更喜欢使用iframe来保留
用户的安全性和信任。如果一个小部件需要内联（并且
中等允许，例如不是iGoogle和朋友）使用内联但敢于
不利用用户信任！
窗口小部件安装程序：在您的博客中安装窗口小部件时，您在窗口小部件上看不到
a用户安全功能区。如何判断
小部件是否安全？我可以建议两种方法：1）
信任供应商2）阅读代码。您可以信任小部件
提供程序并安装它，或者您花时间阅读其代码
并确定自己是否值得信赖。现实是
，大多数网站所有者都不会费心阅读代码，或者甚至不知道他们将用户带来的风险是
，因此小部件提供商
是盲目信任的。在许多情况下，这不是问题，因为博客
通常不会保存有关其读者的个人信息。我怀疑
一旦有很少的高调漏洞就会开始改变
（我希望它永远不会达到它）。
用户：Usres一直处于黑暗中。正如网站所有者安装的小部件上没有安全用于
用户的条带一样，没有安全到
使用的网站，基本上用户一直处于黑暗中并且不知道，
即使他们具备技术技能，他们
使用的网站是否包含小部件，小部件是否内联，以及
是否是恶意的。虽然从理论上讲，经过培训的开发人员可以预先检查代码，然后在她的浏览器中运行代码，并将她的电子邮件帐户丢失给bcker，但这不实用，并且
应该是没有期望用户群众会这样做。 IMO这是
一个不幸的情况，我只希望攻击者找不到利用这个的方式
，并在网上毁灭美妙的开放小部件文化
。
快乐的小工具人！
- 有些博客平台的小部件结构有些不同，有时可能会有可能
的小部件和插件在它们的功能上相关联，但是对于讨论的问题
这里我将使用术语小部件来讨论
由客户端组成的原始类型边javascript代码
**虽然在大多数情况下你需要小部件从托管页面继承样式以使它们看起来与它一致，但有时你
实际上不希望小部件继承样式来自该页面，所以在
这种情况下iFrames允许你从头开始你的CSS。
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.
Can someone please tell me the trade offs between the 2 approaches(IFrame versus JS)?
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/
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.
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.
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.
How is it technically done? How to use an iframe or how to implement an inline widget?
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′ 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(); 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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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!
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).
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.
Happy widgeting folks!
- Some blog platforms have a somewhat different structures for widgets and they may sometimes have both widgets and plugins that may correlate in their functionality, but for the matter of the discussion here I’ll lously use the term widget to discuss the "raw" type which consists of client side javascript code ** Although in most cases you’d want widgets to inherit styles from the hosting page to make them look consistent with it, sometimes you actually don’t want the widget to inherit styles from the page, so in this case iFrames let you start your CSS from scratch.
这篇关于小部件 - Iframe与JavaScript的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
