Je comprends qu'il n'y a aucun moyen de tuer le disjoncteur iframe ... Cependant, je me demandais, est-il un moyen de le manipuler avec élégance.Comment gérer avec élégance le disjoncteur iframe?
Jusqu'à présent, j'ai réussi à le détecter avant de quitter, en utilisant <body onunload="function();">. Je me demandais s'il est possible de l'empêcher de charger le iframe ou le forcer à ouvrir dans la nouvelle fenêtre, etc.
Cheers, Mickey
En fait, vous pouvez réellement faire ce que vous voulez vraiment faire, ce qui est bust the iframe buster. La technique vous permet d'utiliser onbeforeunload pour retourner la page à la vôtre, mais indirectement, car les navigateurs sont trop intelligents pour vous permettre de définir l'URL dans onbeforeunload. Ainsi, à la place, onbeforeunload définit une variable d'indicateur pour marquer que l'URL a changé, et vous interrogez périodiquement cette variable en utilisant une routine setInterval établie lors du chargement de votre page. Tant que vous interrogez assez rapidement pour saisir le changement de variable, vous pouvez vous y connecter et modifier vous-même l'URL de la page. L'astuce consiste à le changer en une page qui renvoie un 204, un statut spécial qui indique au navigateur de laisser la page en cours seule.
Cela dit, il s'agit d'un jeu de chat et de souris. Découvrez Jeff Attwood's StackOverflow question on this, où il demande comment faire sauter la technique ci-dessus. Les pages Web peuvent casser le buster buster en battant l'intervalle d'interrogation; Fondamentalement, ils définissent l'URL pour pointer vers une page minuscule, et celui qui a déjà été mis en cache. Dès que l'URL change pour cette page, elle se chargera plus vite que la routine d'interrogation peut sauter et remarquera que la variable indicateur a changé.
Il n'est pas facile d'empêcher le chargement du cadre en premier lieu. Si vous le vouliez vraiment, vous pourriez demander à votre serveur de télécharger la page et d'analyser le Javascript pour voir si la technique iframe-busting est présente. Cependant, à moins d'émuler un navigateur, vous ne pouvez vous fier qu'à un filtrage de base et il serait facile pour une page de le contourner. (par exemple, utilisez top ["l" + "ocation"] au lieu de top.location).
Une technique plus intelligente serait de suivre les URL redirigeant à l'aide de requêtes Ajax vers le serveur. (par exemple, si l'iframe est toujours là après son chargement, envoyez une requête Ajax à votre serveur). Vous ne pouvez pas garantir à 100% l'exactitude de ces demandes, puisqu'elles proviennent du navigateur, mais vous pouvez au moins les utiliser pour constituer une liste noire manuelle.
Vous ne pouvez pas non plus forcer l'iframe à sortir dans une autre fenêtre.
Vous parlez d'un top.location de réglage iframe intégré? Il n'y a aucun moyen d'empêcher cela pour autant que je sache.
Si le contenu d'un iframe ne vous convient pas, vous pouvez envisager de nettoyer le contenu de ce cadre et de l'héberger vous-même. Évidemment, c'est très délicat, mais c'est à peu près la seule vraie solution. Voir Caja pour un projet qui fait cela. Cela limite bien sûr ce que vous pouvez réellement héberger (si le code que vous hébergez utilise XHR, vous avez de la chance, par exemple).
Vous pouvez utiliser the sandbox attribute introduit en HTML5 pour empêcher le buster iframe. Il suffit de ne pas inclure dans la liste blanche allow-top-navigation:
<iframe sandbox="allow-forms allow-popups allow-pointer-lock allow-same-origin allow-scripts"
src="foo.html"></iframe>
Donc, vous dites que, par exemple ... Si Google a top.location, il va encore charger mais empêcher le top.location de s'exécuter? Le lien iframe src est supposé provenir de sites externes. Donc, quand d'autres sites essaient de top.location = "", cela sera évité. Cependant, je ne suis pas clair à propos de Caja. Est-ce une application basée sur un serveur? –
Caja réécrit javascript pour l'assainir et lui permettre seulement l'accès à un sous-ensemble du DOM. Une des choses auxquelles le code cajolé n'est pas autorisé est 'top'. Ceci est une bonne solution lorsque l'auteur de l'iframe que vous intégrez sait que son contenu va être intégré, car vous avez besoin de standards autour de ce que vous allez exposer à son code. Un bon exemple de ceci est Apache Shindig (http://incubator.apache.org/shindig/), qui permet l'intégration de gadgets et le cajolage. –