El document.domain méthode
- Type de méthode : iframe .
Notez qu'il s'agit d'une méthode iframe qui définit la valeur de document.domain à un suffixe du domaine actuel. Si elle le fait, le domaine le plus court est utilisé pour les contrôles d'origine ultérieurs. Par exemple, supposons qu'un script dans le document à http://store.company.com/dir/other.html exécute l'instruction suivante :
document.domain = "company.com";
Après l'exécution de cette déclaration, la page passe la vérification de l'origine avec http://company.com/dir/page.html . Cependant, par le même raisonnement, company.com ne pourrait pas fixer document.domain à othercompany.com .
Avec cette méthode, vous seriez autorisé à extraire le javascript d'un iframe situé dans un sous-domaine sur une page située dans le domaine principal. Cette méthode n'est pas adaptée aux ressources inter-domaines, car les navigateurs comme Firefox ne vous permettront pas de modifier l'adresse de l'utilisateur. document.domain à un domaine complètement étranger.
Source : https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript
La méthode de partage des ressources inter-origines
Partage de ressources inter-origine (CORS) est un projet de travail du W3C qui définit la manière dont le navigateur et le serveur doivent communiquer lors de l'accès à des sources d'origines différentes. L'idée de base de CORS est d'utiliser des en-têtes HTTP personnalisés pour permettre au navigateur et au serveur d'en savoir suffisamment l'un sur l'autre pour déterminer si la demande ou la réponse doit aboutir ou non.
Pour une demande simple, qui utilise soit GET o POST sans en-tête personnalisé et dont le corps est text/plain la demande est envoyée avec un en-tête supplémentaire appelé Origin . L'en-tête Origin contient l'origine (protocole, nom de domaine et port) de la page requérante afin que le serveur puisse facilement déterminer s'il doit ou non servir une réponse. Un exemple Origin L'en-tête pourrait ressembler à ceci :
Origin: http://www.stackoverflow.com
Si le serveur décide que la demande doit être autorisée, il envoie un message Access-Control-Allow-Origin renvoyant la même origine que celle qui a été envoyée ou * si c'est une ressource publique. Par exemple :
Access-Control-Allow-Origin: http://www.stackoverflow.com
Si cet en-tête est manquant, ou si les origines ne correspondent pas, le navigateur rejette la demande. Si tout va bien, le navigateur traite la demande. Notez que ni les demandes ni les réponses ne contiennent d'informations sur les cookies.
L'équipe de Mozilla suggère dans leur billet sur CORS que vous devez vérifier l'existence de la withCredentials pour déterminer si le navigateur prend en charge CORS via XHR. Vous pouvez alors coupler avec l'existence de la propriété XDomainRequest pour couvrir tous les navigateurs :
function createCORSRequest(method, url){
var xhr = new XMLHttpRequest();
if ("withCredentials" in xhr){
xhr.open(method, url, true);
} else if (typeof XDomainRequest != "undefined"){
xhr = new XDomainRequest();
xhr.open(method, url);
} else {
xhr = null;
}
return xhr;
}
var request = createCORSRequest("get", "http://www.stackoverflow.com/");
if (request){
request.onload = function() {
// ...
};
request.onreadystatechange = handler;
request.send();
}
Notez que pour que la méthode CORS fonctionne, vous devez avoir accès à tout type de mécanisme d'en-tête de serveur et ne pouvez pas simplement accéder à une ressource tierce.
Source : http://www.nczonline.net/blog/2010/05/25/cross-domain-ajax-with-cross-origin-resource-sharing/
El window.postMessage méthode
- Type de méthode : iframe .
window.postMessage lorsqu'il est appelé, provoque un MessageEvent à envoyer à la fenêtre cible lorsque tout script en suspens qui doit être exécuté se termine (par exemple, les gestionnaires d'événements restants si window.postMessage est appelé depuis un gestionnaire d'événements, les délais d'attente définis précédemment, etc.) Le site MessageEvent a le type message, un data qui est définie comme la valeur de la chaîne de caractères du premier argument fourni à l'utilisateur. window.postMessage , un origin correspondant à l'origine du document principal dans la fenêtre appelante. window.postMessage à l'époque window.postMessage a été appelé, et un source qui est la fenêtre à partir de laquelle window.postMessage s'appelle.
Pour utiliser window.postMessage un écouteur d'événements doit être attaché :
// Internet Explorer
window.attachEvent('onmessage',receiveMessage);
// Opera/Mozilla/Webkit
window.addEventListener("message", receiveMessage, false);
Et un receiveMessage doit être déclarée :
function receiveMessage(event)
{
// do something with event.data;
}
L'iframe hors site doit également envoyer correctement les événements via postMessage :
<script>window.parent.postMessage('foo','*')</script>
Toute fenêtre peut accéder à cette méthode sur toute autre fenêtre, à tout moment, indépendamment de l'emplacement du document dans la fenêtre, pour lui envoyer un message. Par conséquent, tout auditeur d'événements utilisé pour recevoir des messages doit d'abord vérifier l'identité de l'expéditeur du message, en utilisant les propriétés d'origine et éventuellement de source. On ne saurait trop insister sur ce point : Le fait de ne pas vérifier le origin et éventuellement source permet des attaques de type "cross-site scripting".
Source : https://developer.mozilla.org/en/DOM/window.postMessage
