Une question sur la requête ajax inter-domaine (sous-domaine)

Question

Disons que j'ai la page principale chargée de http://www.example.com/index.html. Sur cette page, il y a un code js qui fait une requête ajax à http://n1.example.com//echo?message=hello. Lorsque la réponse est reçue, un div sur la page principale est mis à jour avec le corps de la réponse.

Cela fonctionnera-t-il sur tous les navigateurs populaires?

Edit:

La solution évidente est de mettre une procuration devant www.example.com et n1.example.com et faites en sorte que chaque demande d'aller à un sous-ressource de http://www.example.com/n1 se http://n1.example.com/ à proxy.

Answer 1

Une autre solution qui peut ou ne peut pas fonctionner pour vous consiste à insérer/supprimer dynamiquement des balises de script dans votre DOM qui pointent vers le domaine cible. Cela fonctionnera si la cible renvoie json et prend en charge un rappel.

fonction pour gérer le résultat:

<script type="text/javascript"> 
    function foo(result) { 
    alert(result); 
    } 
</script> 

Au lieu de faire une requête AJAX vous insérer dynamiquement quelque chose comme ceci:

<script type="text/javascript" src="http://n1.example.com/echo?callback=foo"></script> 

Answer 2

Une autre solution consiste à diriger la demande ajax à un php (par exemple) page sur votre domaine, et dans cette page faire une requête cURL au sous-domaine.

Answer 3

Cross domain est entièrement un sujet différent. Mais le sous-domaine transversal est relativement facile. Tout ce que vous avez à faire est de définir le document.domain à la fois dans la page parente et dans la page iframe.

document.domain = "yourdomain.com" 

More info here

Note: cette technique will only let you interact with iframes from parents of your domain. Il ne pas modifier l'origine envoyée par XMLHttpRequest.

Answer 4

Nouvelle idée: si vous voulez un sous-domaine croisé (www.domain.com et sub.domain.com) et que vous travaillez sur apache. les choses peuvent être beaucoup plus faciles. si un sous-domaine est en fait un sous-répertoire de public_html (sub.domain.com = www.domain.com/sub/), donc si vous avez ajax.domain.com/?request=subject ... vous pouvez faire quelque chose comme ça: www .domaine.com/ajax /? request = sujet

fonctionne comme un charme pour moi, et pas de hacks stupide, proxies ou des choses difficiles à faire pour seulement quelques requêtes Ajax!

Answer 5

j'ai écrit une solution pour le contre . sous-domaine et son travaille pour mes applications je iframe et la mise en document.domain = « domain.com » des deux côtés Vous pouvez trouver ma solution à:.

https://github.com/emphaticsunshine/Cross-sub-domain-solution

Answer 6

La solution la plus simple que j'ai trouvée était de créer un php sur votre sous-domaine et d'y inclure votre fichier de fonction original en utilisant un chemin complet.

Exemple:

www.domain.com/ajax/this_is_where_the_php_is_called~~V~~3rd.php

Subdomain:

sub.domain.com

Créer: sub.domain.com/I_need_the_function.php

intérieur I_need_the_function.php il suffit d'utiliser un include:

include_once ("/ serveur/chemin/public_html/ajax/this_is_where_the_php_is_called.php");

Appelez maintenant sub.domain.com/I_need_the_function.php depuis votre javascript.

var sub=""; 
switch(window.location.hostname) 
{ 
case "www.domain.com": 
sub = "/ajax/this_is_where_the_php_is_called.php"; 
break; 
case "domain.com": 
sub = ""; 
break; 
default: ///your subdomain (or add more "case" 's) 
sub = "/I_need_the_function.php"; 
} 


xmlHttp.open("GET",sub,true); 

L'exemple est aussi simple que je peux le faire. Vous souhaiterez peut-être utiliser des chemins mieux formatés.

J'espère que cela aide quelqu'un. Rien de désordonné ici - et vous appelez le fichier original, donc les modifications s'appliqueront à toutes les fonctions.

Answer 7

Tous les navigateurs modernes prennent en charge CORS et désormais nous devrions tirer parti de cette addition.

Il fonctionne sur la technique de prise de contact simples étaient les 2 domaines qui communiquent la confiance entre eux par des en-têtes HTTP envoyés/reçus. Cela était attendu depuis longtemps car la même politique d'origine était nécessaire pour éviter XSS et d'autres tentatives malveillantes.

Pour lancer une requête croisée d'origine, un navigateur envoie la requête avec un en-tête HTTP d'origine. La valeur de cet en-tête est le site qui a servi la page. Par exemple, supposons qu'une page sur http://www.example-social-network.com tente d'accéder aux données d'un utilisateur dans online-personal-calendar.com. Si implémente CORS, l'en-tête de la demande suivante du navigateur de l'utilisateur sera envoyé:

Origine: http://www.example-social-network.com

Si online-personal-calendar.com permet la demande, il envoie un en-tête Access-Control-Allow-Origin sa réponse. La valeur de l'en-tête indique quels sites d'origine sont autorisés. Par exemple, une réponse à la demande précédente contiendrait les éléments suivants:

Access-Control-Allow-origine: http://www.example-social-network.com

Si le serveur ne permet pas à la demande croisée d'origine, le navigateur livrera une erreur page exemple-social-network.com au lieu de la réponse online-personal-calendar.com.

Pour autoriser l'accès à toutes les pages, un serveur peut envoyer l'en-tête de réponse suivante:

Access-Control-Allow-origine: *

Cependant, cela pourrait ne pas convenir à des situations dans lesquelles la sécurité est une préoccupation.

très bien expliqué ici en page ci-dessous wiki. http://en.wikipedia.org/wiki/Cross-origin_resource_sharing