Widget – Iframe versus JavaScript

Je cherchais la même question et j'ai trouvé cet article intéressant:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/

Les widgets sont des applications Web petites qui peuvent être facilement ajoutées à n'importe quelle page Web. Ils sont parfois appelés Gadgets et sont largement utilisés dans un nombre croissant de pages Web, blogs, sites sociaux, pages d'accueil personnalisées telles que iGoogle, Yahoo, netvibes, etc. Dans ce blog, j'utilise plusieurs widgets, comme le compteur RSS à droite Qui indique le nombre d'utilisateurs inscrits sur ce blog (ne vous inquiétez pas, ça va croître, c'est un nouveau blog ;-)). Les widgets sont géniaux en ce sens qu'ils sont une petite fonctionnalité réutilisable qui même les non-programmeurs peuvent utiliser pour enrichir leur site.

J'ai écrit plusieurs de ces widgets au fil du temps, les widgets "bruts" qui peuvent être intégrés dans n'importe quel site ainsi que des gadgets iGoogle qui sont plus structurés, worpress *, typepad et widgets de blogger, donc je suis heureux de partager mon expérience.

En tant qu'auteur de widget, pour les widgets qui fonctionnent du côté client (code HTML simple incorporé), vous avez le choix entre l'écriture de votre widget dans un iframe ou simplement la page en ligne et la faire partie intégrante de la page d'hébergement. Le reste de la publication traite des avantages et inconvénients des deux méthodes.

Comment cela se fait-il techniquement? Comment utiliser un iframe ou comment implémenter un widget en ligne?

Les iframes sont un peu plus faciles à mettre en œuvre. L'exemple suivant rend un simple widget iframe: http://my-great-widget.com/widgwt 'width = "100" height = "100" frameborder =' 0 '>

Frameborder = '0' est utilisé pour s'assurer que l'ifrmae n'a pas de bordure, donc il semble plus naturel sur la page. Le http://my-great-widget.com/widget est responsable de servir le contenu du widget en tant que page HTML complète.

Les gadgets en ligne pourraient ressembler à ceci:

Function createMyWidgetHtml () {retournez "Hello world of widgets"; } Document.getElementById ('myWidget'). InnerHTML = createMyWidgetHtml (); Comme vous pouvez le voir, la fonction createMyWidgetHtml () est responsable de créer le contenu du widget réel et ne doit pas nécessairement parler à un serveur pour le faire. Dans l'exemple iframe, il doit y avoir un serveur. Dans l'exemple en ligne, il n'est pas nécessaire d'avoir un serveur, mais si nécessaire, il est possible d'obtenir des données du serveur, ce qui est en fait un cas très commun, les widgets n'appellent généralement le code côté serveur. L'utilisation de la méthode en ligne Le code côté serveur est invoqué au moyen d'un javascript on-demmand.

Donc, pour résumer, dans l'affaire iframe, nous mettons simplement un code HTML iframe et indiquons la source de l'iframe dans un emplacement grave qui sert réellement le contenu du widget. Dans le cas en ligne, nous créons le contenu localement à l'aide de javascript. Vous pouvez bien sûr combiner l'utilisation de l'iframe avec javascript ainsi que l'utilisation de la méthode en ligne avec les appels côté serveur, vous n'êtes pas restreint par cela, mais les chemins commencent différemment.

Alors, quel est l'affaire? Quelle est la différence? Il existe plusieurs différences importantes, donc ici commence la partie intéressante de la publication.

Sécurité. Les widgets iFrame sont plus sécurisés.

Quels sont les risques imposés par les gadgets et qui sont en danger? L'utilisateur du site et la réputation du site sont à risque.

Avec les gadgets en ligne, le navigateur pense que la source du code de gadget provient du site d'hébergement. Supposons que vous naviguez sur votre application de messagerie préférée http://my-wonderful-email.com et que cette application de messagerie a installé un widget qui affiche une horloge à partir de http://great-clock-widgets.com/ . Si ces widgets sont implémentés en tant que widget en ligne, le navigateur pense que le code du widget est originaire de my-wonderful-email.com et non pas à great-clock-widgets.com et donc il va permettre au code du widget d'accéder aux cookies Appartenant à my-wonderful-email.com et l'auteur malveillant du widget volera votre courrier électronique. Il est important de se rendre compte que les navigateurs ne se soucient pas d'où le fichier javascript est hébergé; Tant que le code s'exécute sur le même cadre, le navigateur considère tout le code comme originationg sur le domaine de l'image. Ainsi, vous, en tant qu'utilisateur, vous blessez en perdant le contrôle de votre compte de messagerie et mon email merveilleux est blessé en perdant sa réputation.

Si la même horloge aurait été implémentée à l'intérieur d'un iframe et que la source de l'iframe est différente de la source de la page (ce qui est le cas commun, par exemple, la source de la page est my-wonderful-email.com et la source du gadget est une grande horloge .com), le navigateur n'autoriserait pas les widgets de l'horloge à accéder aux cookies de la page, et ne permettra pas d'accéder à une autre partie du document d'hébergement, y compris la page d'accueil. C'est plus sécurisé. En fait, les pages d'accueil personnelles telles que iGoogle n'autorisent même pas les gadgets en ligne, seuls les gadgets iframe sont autorisés. (Les gadgets en ligne ne sont autorisés que dans de rares cas, uniquement après une inspection approfondie de l'équipe iGoogle pour s'assurer qu'ils ne sont pas malveillants)

Pour résumer, les widgets iframe sont beaucoup plus sécurisés. Cependant, ils sont également plus limités en fonctionnalité. Ensuite, nous discuterons de ce que vous perdez dans la fonctionnalité.

Regardez et sentez-vous Dans les gadgets inline de look and feel battle (habituellement **). La bonne chose à leur sujet, c'est qu'ils peuvent être conçus pour faire partie de la page. Ils peuvent hériter des styles CSS de la page, y compris les polices, les couleurs, la taille du texte, etc. L'Iframe, OTHO doit définir leur CSS à partir des motifs, donc il est très difficile pour eux de bien mélanger dans la page.

Mais ce qui est encore plus important, c'est que les iframes doivent déclarer quelle sera leur taille. Lors de l'ajout d'un iframe à une page, vous devez inclure une propriété de largeur et de hauteur et, si vous ne le faites pas, le navigateur utilisera certains paramètres par défaut. Maintenant, si votre widget est un widget d'horloge assez simple b / c, vous savez exactement quelle taille vous voulez, mais dans de nombreux cas, vous ne savez pas à l'avance combien d'espace votre widget va prendre. Si, par exemple, vous créez un widget qui affiche une liste de sorte et que vous ne savez pas combien de temps cette liste sera ou quelle sera l'ampleur de chaque élément. Habituellement, en HTML, ce n'est pas grave parce que HTML est une langue déclarative, donc tout ce que vous devez faire est de dire au navigateur ce que vous souhaitez afficher et le navigateur trouvera une mise en page raisonnable, mais avec iframe ce n'est pas le Cas; Avec les navigateurs ifrmaes exigent que vous lui disiez exactement quelle est la taille de l'iframe et que cela ne le comprendra pas seul. C'est un vrai problème pour les auteurs de widget qui veulent utiliser les iframes – si vous avez besoin de trop d'espace, la page aura des vides et si vous spécifiez trop peu, la page aura des barres de défilement, Dieu interdit.

Regardez et sentez-vous sage, gagne en ligne. Mais notez que cela dépend vraiment de votre application de widget. Si tout ce que vous voulez faire est une horloge, vous pouvez vous lier avec un iframe tout aussi bien.

Le côté Serveur vs Les IFrmaes du côté client exigent que vous spécifiez une URL src, alors, lors de la mise en œuvre d'un widget à l'aide d'un iframe, vous devez avoir un code côté serveur. Cela pourrait être une limitation et un mal de tête à certains (possédant un serveur, un nom de domaine, etc., traitant de la charge, payant des factures de réseau, etc.) mais à d'autres, c'est en fait un point en faveur de l'iframe b / c, il vous permet d'écrire complètement votre Des widgets dans les technologies du côté serveur, afin que vous puissiez écrire beaucoup du code et, en fait, presque tout cela en utilisant votre technologie côté serveur préférée, que ce soit asp.net, django, ror, jsp, struts, perl ou d'autres dinosaures. Lors de la mise en œuvre d'un gadget en ligne, vous allez de plus en plus pratiquer votre Ninja javascript.

Quel est l'algorithme de décision alors? Auteur des widgets: si le widget peut être implémenté comme un iframe, préférez un Iframe simplement pour préserver la sécurité et la confiance des utilisateurs. Si un widget nécessite une mise en ligne (et que le support le permet, par exemple, pas iGoogle et les amis), utilisez en ligne mais n'osez pas exploiter les utilisateurs en confiance!

Installateurs de widgets: lors de l'installation d'un widget dans votre blog, vous ne voyez pas un ruban "sécurisé pour les utilisateurs" sur les widgets. Comment pouvez-vous savoir si le widget est sécurisé ou non? Il y a deux alternatives que je peux suggérer: 1) faire confiance au vendeur 2) lire le code. Soit vous faites confiance au fournisseur de widgets et installez-le de toute façon, soit vous prenez le temps de lire son code et de vous déterminer s'il est digne de confiance ou non. La réalité est que la plupart des propriétaires de sites ne dérangent pas de lire le code ou ne sont même pas conscients du risque qu'ils mettent leurs utilisateurs, et les fournisseurs de widgets sont aveuglément fiables. Dans de nombreux cas, ce n'est pas un problème puisque les blogs ne possèdent généralement pas d'informations personnelles sur leurs lecteurs. Je soupçonne que les choses commenceront à changer une fois qu'il y a peu d'exploits de haut profil (et j'espère que ça ne le fera jamais).

Utilisateurs: Usres sont conservés dans l'obscurité. Tout comme il n'y a pas de rubans «sécurisés pour les utilisateurs» sur les installateurs des sites, les sites ne contiennent pas de sites «sûrs à utiliser» et, fondamentalement, les utilisateurs sont gardés dans l'obscurité et n'ont aucune idée, même s'ils ont les compétences techniques, qu'ils soient ou non Le site qu'ils utilisent contient des widgets, que les widgets soient en ligne ou non et qu'ils soient malveillants. Bien qu'en théorie un développeur formé puisse inspecter le code avant de l'exécuter dans son navigateur et de perdre son compte de messagerie à un pirate informatique, mais ce n'est pas pratique et il ne devrait pas y avoir d'attente que les utilisateurs en masse fassent cela. IMO, c'est une condition malheureuse et j'espère seulement que les attaquants ne trouveront pas un moyen de profiter de cela et de condamner la merveilleuse culture de widgets ouverts sur le Web.

Bonne adaptation!

• Certaines plates-formes de blog ont des structures quelque peu différentes pour les widgets et peuvent parfois avoir des widgets et des plugins qui peuvent être en corrélation avec leur fonctionnalité, mais pour la discussion ici, j'utiliserai le terme widget pour discuter du type "brut" qui Se compose du code javascript côté client ** Bien que dans la plupart des cas, vous souhaitez que les widgets héritent des styles de la page d'hébergement pour les rendre compatibles, parfois vous ne voulez pas que le widget hérite des styles de la page. Ce cas iFrames vous permet de démarrer votre CSS à partir de rien.

Pourquoi ne pas faire les deux?

Je préfère offrir aux sites tiers un script comme:

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

Le fichier sur votre serveur ressemble à:

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

METTRE À JOUR:

Le grand inconvénient de l'utilisation d'un iframe qui pointe vers une URL sur votre serveur est que vous ne générez pas un backlink "réel" si quelqu'un clique sur une URL de votre serveur qui pointe vers votre serveur.

Je suis sûr que beaucoup de développeurs / propriétaires de sites apprécieront une solution Javascript qu'ils peuvent adapter à leurs besoins plutôt que d'utiliser un iframe . Si j'allais inclure un composant d'un tiers, je préférerais le faire via Javascript parce que j'aurais plus de contrôle.

En ce qui concerne la facilité d'utilisation, les deux sont similaires dans la simplicité, donc aucun compromis réel là-bas.

Une autre pensée, assurez-vous d'obtenir un certificat SSL pour n'importe quel domaine dans lequel vous hébergez et écrivez l'énoncé d'inclusion en conséquence si la page est diffusée sur SSL. Dans le cas où les propriétaires de votre site ont une raison d'utiliser SSL, ils apprécieront certainement cela, car Firefox et d'autres navigateurs se plaindront lorsqu'une page est fournie avec un mélange de contenu sécurisé / non sécurisé.

Si le widget peut être incorporé dans un iframe, il sera préférable pour la performance frontend du site d'hébergement car les iframes ne bloquent pas le téléchargement de contenu. Cependant, comme d'autres ont commenté, d'autres inconvénients à l'utilisation d'iframes.

Si vous mettez en œuvre javascript, considérez les meilleures pratiques de performance avant lors du développement. En particulier, vous devez regarder le chargement javascript non bloquant . Google Analytics et d'autres fournisseurs de widgets tiers supportent cette méthode de chargement. Cela aiderait aussi si vous pouvez charger le javascript au bas de la page.

Je suis content de ne pas être déployé dans un site de réseautage social … qui quitte simplement le reste du Web 😉

Ce qui serait le plus utile dépend de votre widget. IFrames et javascript servent généralement à des fins tout à fait différentes, et peuvent être mélangés (c.-à-j. Javascript dans un iframe ou javascript créant un iframe).

• Les IFrames ont des problèmes de dimensionnement; S'il est censé correspondre exactement à la page, savez-vous qu'il rend la même chose sur tous les navigateurs, les données ne débordent pas le conteneur, etc.?
• Les IFrames sont simples. Ils peuvent être une page HTML simple et statique.
• Lorsque vous utilisez IFrames, vous exposez votre widget de manière très claire.
• Mais encore une fois, pourquoi ne pas avoir votre site tiers inclure simplement le HMTL à une url donnée? Le HTML peut ensuite être étendu pour contenir javascript lorsque / si vous en avez besoin.
• Pure Javascript permet une plus grande flexibilité mais au prix d'une certaine complexité.

Le grand plus d'iframes: tous les CSS et JS sont séparés de la page hôte, donc votre CSS existant fonctionne. (Si vous souhaitez que le site hôte forme votre contenu pour s'adapter, c'est moins bien sûr.)

Le grand inconvénient des iframes: ils ont une largeur et une hauteur fixes et des barres de défilement apparaîtront si votre contenu est plus grand.