Qu'est-ce que l'accès inter-domaines Ajax

L'accès inter-domaines AJAX signifie que lorsqu'un utilisateur visite le site Web A, toutes les demandes d'accès inter-domaines au site Web B sont soumises à la page désignée du site Web A. Autrement dit, Ajax demande une ressource Web dont l'adresse cible est un domaine non local (le protocole, le nom de domaine et le port sont différents) et obtient des données d'application externe en fonction de la réponse.

Ajax demande une ressource Web dont l'adresse cible est un domaine non local (le protocole, le nom de domaine et le port sont différents) et obtient une application externe données basées sur la réponse. Par exemple, lorsque nous utilisons Ajax pour accéder à des interfaces de service public telles que les prévisions météorologiques de la ville et l'adresse IP, plusieurs domaines sont impliqués. Lorsque nous demandons un service externe, le navigateur refuse l'accès autorisé en raison de problèmes de sécurité.

Les attributs src des balises script, script et iframe ne présentent pas de problèmes inter-domaines, donc Ajax cross-domain en profite et la prise en charge de JS pour JSON n'a besoin que de répondre à un code JS. pour les requêtes Ajax. Ou les données JSON peuvent être obtenues par Ajax.

Pour des raisons de sécurité, le client js ne peut utiliser xmlhttprequest que pour envoyer des requêtes au site Web source. Par exemple, il n'est pas possible de demander des données à test.readlog.cn sur www.readlog.cn. Il existe cependant de nombreuses solutions. Faisons le tri ici.

Solution 1 Méthode proxy Web (sur le serveur A)

Cette page remplace la page utilisateur pour terminer l'interaction, renvoyant ainsi les résultats appropriés. Cette solution peut résoudre la plupart des problèmes d'accès entre domaines auxquels on peut penser à ce stade, mais elle nécessite que le site Web A fournisse un support proxy Web. Par conséquent, le site Web A et le site Web B doivent coopérer étroitement, et chaque processus d'interaction, le serveur. du site Web A La charge augmente et l'état de la session ne peut pas être enregistré au nom de l'utilisateur.

Solution 2. Méthode à la demande (sur le serveur A)

Le portail MYMSN utilise cette méthode, mais MYMSN n'implique pas de problèmes d'accès inter-domaines. Générez dynamiquement de nouveaux

dans la page Solution 3. méthode iframe (sur le serveur A)
J'ai consulté un article sur l'accès inter-domaines sur JavaEye. le problème d'accès inter-domaines à l'aide d'iframe. Il est en effet possible d'utiliser iframe pour la soumission et l'acquisition de données, mais comme la fenêtre parent et la fenêtre enfant ne peuvent pas interagir (en cas d'accès inter-domaines, cette interaction est rejetée), l'effet sur la fenêtre parent ne peut pas être complété.
Intégrez-le dans la page ou générez dynamiquement un IFRAME pointant vers un autre site Web, puis les deux pages Web peuvent transmettre des messages en modifiant mutuellement le fragment de hachage d'ancrage. La modification du fragment de hachage d'ancre d'une page Web n'entraîne pas le rechargement de la page Web par le navigateur, de sorte que l'état d'une page Web est conservé et la page Web elle-même peut détecter les changements dans son hachage d'ancre via une minuterie, et ainsi modifier son propre état de hachage d’ancre en conséquence.

Solution 4. Méthode de vidage local de l'utilisateur (local)
Les caractéristiques d'IE lui-même attaché à la plate-forme Windows nous fournissent une méthode basée sur l'iframe qui utilise la mémoire pour "contourner" "La solution est que les données peuvent être transmises entre deux fenêtres via le presse-papiers de Windows sur le client. Il suffit de définir l'intervalle du côté recevant les données pour l'interrogation et d'effacer l'intervalle après avoir obtenu le résultat. L'indépendance de la plate-forme de FF détermine qu'il ne prend pas en charge la méthode du presse-papiers et la vulnérabilité du plug-in dans les versions précédentes de FF a été corrigée, de sorte que FF ne peut pas terminer le passage secret à travers la mémoire. Et comme FF ne prend pas en charge les opérations sur les fichiers (le transfert de données ne peut pas être effectué entre domaines via des cookies), cette méthode technique ne peut être utilisée que dans IE.

Solution 5 : (En fait, le problème de communication avec le serveur B est résolu en utilisant l'iframe sur le serveur A)
Le problème à résoudre : survient lorsque l'utilisateur soumet le URL de la page Web (incluant également la balise, les notes, etc.) vers le serveur de favoris.
Il existe au moins trois façons de soumettre des URL :
1. Connectez-vous à la page de soumission du serveur de favoris et soumettez l'URL à collecter au serveur via cette page.
2. Installez le plug-in du navigateur et soumettez l'URL au serveur via le plug-in.
3. Chargez dynamiquement le gadget javascript du serveur de favoris vers la page actuelle et utilisez-le pour terminer le travail de soumission.

La première méthode est la plus simple à développer, mais elle est plus gênante pour les utilisateurs. Chaque fois qu'ils doivent se connecter au serveur Bookmark pour terminer la soumission, je ne connais pas le plug-in ; développement, et les utilisateurs ne la connaissent pas. J'aime trop de plug-ins pour remplir mon navigateur ; la troisième méthode est facile à développer et évite la difficulté de se connecter au serveur à chaque fois, donc je l'ai finalement adoptée. En plus de générer une interface utilisateur permettant aux utilisateurs de remplir des informations (URL, balise, notes, etc.), le gadget javascript chargé dynamiquement dans la troisième méthode doit également remplir la fonction de communication avec le serveur lorsque l'utilisateur clique sur Soumettre.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!