Le développement Web nécessite souvent des problèmes de domaine transversal. La cause profonde des problèmes du domaine croisé est la stratégie de même originale dans la sécurité du navigateur. Par exemple, pour http://www.a.com/1.html:
1. Http://www.a.com/2.html est homologue;
2. Https://www.a.com/2.html provient de différentes sources, car le protocole est différent;
3. Http://www.a.com:8080/2.html provient de différentes sources, car les ports sont différents;
4. http://sub.a.com/2.html provient de différentes sources car les hôtes sont différents.
Dans le navigateur, les balises <cript>, <img>, <frame> et <nk> peuvent charger des ressources croisées (non homologues), et la méthode de chargement est en fait équivalente à une demande de GET ordinaire. La seule différence est que pour la sécurité, le navigateur n'autorise pas les opérations de lecture et d'écriture sur les ressources chargées de cette manière, mais ne peut utiliser que les capacités que la balise elle-même devrait avoir (comme l'exécution du script, l'application de style, etc.).
Le problème du domaine croisé le plus courant est le problème d'accès au domaine croisé de l'Ajax. Par défaut, les URL du domaine croisé ne sont pas accessibles via Ajax. Ici, j'enregistre ce que j'ai appris sur les méthodes du domaine croisé:
1. Proxy côté serveur , il n'y a rien à dire. L'inconvénient est que par défaut, le serveur qui reçoit des demandes AJAX ne peut pas obtenir l'IP et l'UA du client.
2. Iframe , l'utilisation d'Iframe est en fait équivalente à l'ouverture d'une nouvelle page Web. La méthode spécifique du domaine croisé est à peu près la page parent ouverte par le domaine A niche un iframe pointant vers le domaine B, puis soumet les données. Une fois terminé, le serveur de B peut:
● Renvoyez une réponse de redirection 302 et pointez le résultat vers le domaine A;
● Nest un iframe pointant vers le domaine A à l'intérieur de cet iframe.
Les deux implémentent enfin les appels inter-domaines. Cette méthode est plus fonctionnellement plus forte que le JSONP introduit ci-dessous, car après l'achèvement du domaine croisé, il n'y a aucun problème avec les opérations DOM et les appels JavaScript entre les autres, mais il y a certaines restrictions, telles que le résultat qui est passé dans les paramètres de l'URL, ce qui signifie que lorsque les données de résultat sont grandes, elles doivent être transmises dans la segmentation, ce qui est très problématique; Il y a un autre problème qui est causé par l'Iframe lui-même, et l'interaction entre la page parent et l'IFRAME elle-même a des restrictions de sécurité.
3. Utilisez des balises de script pour croiser dans le domaine , cette méthode est également très courante. Les balises de script peuvent charger un javascript étranger et les exécuter. La fonction de rappel prédéfinie peut réaliser l'interaction avec la page parent. Il a un grand nom appelé JSONP Cross-Domain, qui est une abréviation pour JSON avec rembourrage. Il s'agit d'un protocole non officiel, qui est évidemment un script de chargement, alors pourquoi est-il lié à JSON? Il s'avère qu'il s'agit de cette fonction de rappel. Il existe un moyen typique de l'utiliser, qui est de transmettre des paramètres via JSON, c'est-à-dire remplir les données JSON dans la fonction de rappel. C'est la signification du rembourrage JSON + de JSONP.
Il existe de nombreux services JSONP sur Internet pour fournir des données. En substance, ce sont des demandes de domaine croisé et spécifient des rappels dans l'URL de la demande, tels que callback = résultat. Après avoir obtenu ces données, la fonction de résultat sera automatiquement appelée et les données seront transmises sous la forme de JSON, par exemple (recherche de "football"):
http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=football&callback=result
Utilisez jQuery pour l'appeler et l'écrire comme:
La copie de code est la suivante:
$ .getjson ("http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=football&callback=?", function (data) {
// ...
});
En général, la limitation de l'approche inter-domaine de JSONP est qu'elle ne peut utiliser que des demandes de GET et ne peut pas résoudre le problème de la façon de passer des appels JavaScript entre deux pages dans différents domaines.
4. Domain transversal flash:
Il accédera au fichier Crossdomain.xml sous le répertoire racine du site Web Target et déterminera s'il faut permettre l'accès à cet accès à domaine croisé en fonction du contenu du fichier:
La copie de code est la suivante:
<cross-domain-policy>
<allow-access-from domain = "xxx.xxx.com" />
</ cross-domain-policy>
5. La balise IMG peut également être utilisée , ce qui est également une méthode très courante. Il a une fonction plus faible et ne peut envoyer une demande GET sans aucun rappel. C'est ainsi que le nombre de clics de Google est déterminé.
6. Window.PostMessage, qui est un mécanisme nouvellement ajouté pour la communication dans le domaine croisé, n'est pris en charge que par Firefox 3, Safari 4, IE8 et ultérieurement. L'appel pour l'utiliser pour envoyer des messages à d'autres fenêtres est le suivant:
La copie de code est la suivante:
otherwindow.PostMessage (message, Targetorigin);
Dans la fenêtre de réception, un gestionnaire d'événements doit être défini pour recevoir les messages envoyés:
La copie de code est la suivante:
Window.AddeventListener ("Message", Recomessage, False);
fonction receiveMessage (événement) {
if (event.orgin! == "http://example.org:8080")
retour;
}
Notez que les attributs d'origine et de source du message doivent être utilisés pour vérifier l'identité de l'expéditeur, sinon il provoquera des vulnérabilités XSS.
7. Contrôle d'accès
Certains navigateurs prennent en charge les en-têtes de réponse comme l'origine-contrôle-allore, tels que:
La copie de code est la suivante:
En-tête ("Access-Control-Allow-Origin: http://www.a.com");
Cela spécifie que l'accès entre domaine à www.a.com est autorisé.
8. Window.Name
Cette chose était en fait utilisée comme moyen de pirater des XS. L'essence est que lorsque l'emplacement de la fenêtre change, la page sera rechargée, mais intéressant, la fenêtre ne change pas, vous pouvez donc l'utiliser pour passer la valeur. Avec l'IFRAME, modifiez plusieurs fois l'objet de fenêtre de l'IFRAME et le transfert pratique des données du domaine intermédiaire est terminé.
9. Document.Domain
Cette méthode convient à la communication inter-domaine telle que A.Example.com et B.Example.com, car les deux ont un domaine commun appelé example.com. Définissez simplement document.domain sur example.com, mais si vous souhaitez communiquer entre a.example1.com et b.example2.com, il n'a pas le choix.
10. Messagerie d'identification des fragments (FIM)
Cette méthode est très intéressante et nécessite la coopération des iframes. L'identifiant de fragment est la partie qui est souvent utilisée pour le positionnement de l'ancrage après la marque de livre de l'URL (#). Les modifications dans cette partie ne provoqueront pas de rafraîchissement de la page. La fenêtre féminine peut accéder à l'URL de l'Iframe à volonté, et l'IFRAME peut également accéder à l'URL de la fenêtre féminine. Ensuite, la communication peut être réalisée en modifiant l'identifiant de fragmations. L'inconvénient est que les changements dans l'identifiant de fragmes généreront des histoires inutiles et auront des restrictions de longueur; De plus, certains navigateurs ne prennent pas en charge l'événement Onhashchange.
11. Frame croisé (CF)
Cette méthode est une variante de la méthode FIM ci-dessus. L'essence de CF et FIM est en fait introduite dans mon article "GWT First Experience" (il est juste utilisé pour implémenter l'histoire et les fonctions arriérées). Il créera dynamiquement un iframe invisible, pointant vers un domaine étranger. Après traitement, l'identifiant de fragment dans l'URL de cette iframe contient les résultats de traitement pour que la page parent d'accéder, tandis que l'URL du navigateur n'a aucun changement.
12. Protocole Cookie + P3P
L'utilisation des caractéristiques des cookies d'accès inter-domaines sous le protocole P3P pour obtenir un accès inter-domaines est également une astuce étrange. P3P est une norme de recommandation de protection de la vie privée publiée par W3C, visant à fournir une protection de la confidentialité aux internautes qui surfent sur Internet. Définissez le chemin du cookie sur "/", c'est-à-dire qu'il n'y a pas de restriction de domaine. Pour le moment, certains navigateurs permettent de lire des pages d'autres URL, tandis que d'autres ne le font pas. Dans ce cas, l'en-tête P3P doit être défini sur la tête de la réponse de la page parent:
La copie de code est la suivante:
P3p: cp = "cura adma deva psao psdo notre bus uni pur int dem sta pre com nav otc noi dsp cor"