English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Résumé des connaissances sur les domaines transversaux en JavaScript :
Avant que le terme "domaine transversal" ne soit couramment utilisé, nous l'avons utilisé fréquemment. Par exemple, pour un img sur un site A, l'attribut src pointe vers une adresse d'image sur un site B, sans aucun doute, cela peut normalement être affiché (et sans parler de la technologie de protection contre le vol de lien); de même, l'attribut src de l'étiquette script peut pointer vers des ressources de scripts sur d'autres sites (dans certains cas, cela est même encouragé, afin de tirer pleinement parti des avantages de charge des autres sites, réduisant ainsi la charge concurrente de son propre serveur). Cependant, si l'on utilise JavaScript pour demander activement des données sur d'autres sites, par exemple via la méthode AJAX, on se heurte à un problème de domaine transversal frustrant, ce que l'on appelle généralement le domaine transversal. Pour des raisons de sécurité, l'accès entre domaines est par défaut interdit par les navigateurs. Cela implique le concept de stratégie de source : la stratégie de source empêche un script chargé depuis un domaine de récupérer ou d'exploiter les attributs du document d'un autre domaine. Autrement dit, le domaine de l'URL demandée doit être le même que le domaine du site Web actuel. Cela signifie que le navigateur isole le contenu provenant de sources différentes pour empêcher les opérations entre eux.
Les problèmes de sécurité spécifiques liés aux domaines transversaux n'ont pas été approfondis par le blogueur, les autres peuvent compléter cela par eux-mêmes.
Cependant, dans de nombreux cas, en particulier aujourd'hui, avec le développement continu de l'internet, nous avons besoin de demander des interfaces frontales provenant de différents partenaires ou fournisseurs de données, avant que la méthode d'accès entre domaines ne soit normalisée (les besoins d'accès entre domaines client semblent également susciter l'intérêt de w3Attention, c, selon les informations, html5 Le standard WebSocket supporte l'échange de données entre domaines, il devrait également être une solution de choix pour l'échange de données entre domaines à l'avenir, quels sont les moyens de contourner ses limitations ? Les réponses sont nombreuses (bien que toutes soient gênantes), la plus courante étant ce que l'on appelle JSONP pour contourner les domaines.
Principe de JSONP
Le principe le plus basique de JSONP est : ajoutez dynamiquement un tag <script>, et l'attribut src du tag <script> n'a pas de restriction de domaine transversal. De cette manière, ce mode de domaine transversal n'a plus rien à voir avec le protocole XmlHttpRequest de Ajax.
JSONP signifie JSON with Padding. En raison des limitations de la stratégie de même origine, XmlHttpRequest n'autorise que la demande de ressources de la même origine (nom de domaine, protocole, port). Si vous souhaitez effectuer une requête de domaine transversal, vous pouvez utiliser le tag html script pour effectuer une requête de domaine transversal et renvoyer le code script à exécuter dans la réponse. Ce mode de communication transversale est appelé JSONP.
Voici un exemple simple :
!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Test Jsonp</title>
<script type="text/javascript">
function jsonpCallback(result)
{
alert(result.msg);
}
</script>
<script type="text/javascript" src="http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback"></script>
</head>
<body>
</body>
</html>
Résumé du principe et du processus : d'abord enregistrer un callback sur le client, puis transmettre le nom du callback au serveur (ici, le client et le serveur conviennent de transmettre la valeur de la chaîne de requête jsonp en tant que clé). À ce moment-là, le serveur génère des données json. Ensuite, sous forme de syntaxe javascript, génère une fonction, le nom de la fonction est le paramètre jsonp transmis. Enfin, placez directement les données json en tant que paramètre dans la fonction, de sorte que génère un document de syntaxe js, renvoyé au client. Le navigateur client analyse le tag script et exécute le document javascript retourné, ce qui équivaut à exécuter la fonction callback prédéfinie.
À partir de cette brève description, on peut en déduire que, en plus de retourner des segments de code js sous forme de fonction, le serveur peut naturellement retourner tous les segments de code js conformes aux normes.
Les缺点 de JSONP est qu'il ne supporte que les demandes GET et non d'autres types de demandes HTTP telles que POST ; il ne supporte que les demandes HTTP de cross-domain, et ne peut pas résoudre le problème de comment deux pages de différents domaines peuvent appeler JavaScript entre elles. (Il y a encore d'autres aspects).
Jsonp de jQuery
Comme mentionné précédemment, jsonp n'est pas une demande ajax, mais jQuery fournit toujours une méthode de demande de cross-domain similaire à jQuery.ajax :
$.ajax({
url: 'http://crossdomain.com/jsonServerResponse',
type: 'GET',
dataType: 'jsonp',
jsonp: "callback",
jsonpCallback: 'functionName',
success: function (data, textStatus, jqXHR) { }
//……
});
Comme indiqué ci-dessus, dataType est réglé sur jsonp, ce qui signifie que c'est une demande de cross-domain. jsonp est le nom de la fonction de passage de l'interface côté serveur, et jsonpCallback est le nom de la fonction js ; si jsonpCallback n'est pas réglé, jQuery générera automatiquement un nom de fonction aléatoire (charge une fonction globale dans l'objet window, qui est exécutée lors de l'insertion du code, et est ensuite supprimée), on peut en déduire que cette fonction générée automatiquement appellera la fonction success mentionnée ci-dessus. (Quand jsonpCallback est assigné manuellement, on ne sait pas si la fonction success sera appelée ou si jQuery cherchera la fonction prédéfinie, et si elle ne la trouve pas, elle renverra une erreur ? L'auteur est paresseux, il le testera plus tard.) Bien sûr, jQuery nous fournit une version simple, $.getJSON, que je ne développerai pas ici.
Il convient de noter que le paramètre jqXHR de la fonction success, dans les demandes ajax, est un objet jqXHR authentique, qui peut également être considéré comme un objet XMLHTTPRequest (hérité ou encapsulé), mais dans les demandes jsonp, ce n'est pas le cas, il ne nous apporte presque pas les informations les plus utiles de XMLHTTPRequest : il manque les informations d'état de la demande de XMLHTTPRequest, donc il ne peut pas déclencher la plupart des fonctions de rappel, telles que error, complete, etc. (jQuery1.9.0), et devrait être déclenché par l'événement load du balise script, ce qui est complètement différent du mécanisme de statut de XMLHttpRequest utilisé par AJAX. Après expérimentation, Zepto (v1.1.3) Lorsqu'une erreur se produit dans une requête jsonp, par exemple lors du chargement du document js, l'en-tête de réponse renvoie401Lorsqu'il y a une erreur, la fonction error est exécutée, mais le paramètre jqXHR de cette fonction n'est pas du type jqXHR authentique, et on ne peut même pas obtenir les informations d'en-tête de la réponse via celui-ci. Dans ce cas, on ne nous est informé que d'une erreur dans un certain processus, mais on ne sait pas quel est l'erreur spécifique. Pour des scénarios où les en-têtes de réponse contiennent des informations utiles, l'auteur ne recommande pas l'utilisation de jsonp, car l'un des prérequis de l'utilisation de jsonp est : en dehors des exceptions non liées aux affaires, telles que les exceptions de réseau, toutes les exceptions liées aux affaires (c'est-à-dire toutes les exceptions qui se produisent pendant la période de demande au serveur à la réception de la réponse) doivent être retournées directement sous forme de résultat de demande au client, ce qui facilite l'analyse de rappel du client.
Merci de votre lecture, j'espère que cela peut vous aider, merci de votre soutien au site !
Déclaration : le contenu de cet article est issu du réseau, propriété des auteurs respectifs, contribué et téléversé par les utilisateurs d'Internet de manière spontanée. Le site Web ne détient pas de propriété intellectuelle, n'a pas été édité par l'homme, et n'assume aucune responsabilité juridique connexe. Si vous trouvez du contenu présumé violer les droits d'auteur, vous êtes invité à envoyer un e-mail à : notice#oldtoolbag.com (veuillez remplacer # par @ lors de l'envoi d'un e-mail pour signaler une violation, et fournir des preuves pertinentes. Une fois vérifié, le site supprimera immédiatement le contenu présumé enfreindre les droits d'auteur.