Je n’ai pas écrit d’essai depuis longtemps, et j’ai toujours l’impression de ne pas avoir le temps, mais en fait, le temps est... Assez de bêtises, il y a quelques jours, une nouvelle exigence est apparue au travail, qui exigeait que la page web du front-end appelle la méthode du service web backend de manière asynchrone pour renvoyer des informations. Il existe de nombreuses façons de l’implémenter, cet exemple utilise jQuery+Ajax, une fois terminé, tout est correct pour déboguer localement, mais il y a un problème après le déploiement sur le serveur, et l’appel de service en arrière-plan ne répond pas, que se passe-t-il ? Le code n’a pas beaucoup changé, la seule chose qui a changé est l’adresse URL dans la méthode ajax de jQuery. Se pourrait-il que le problème ici vienne du fait qu’après vérification et débogage, il s’avère que la politique homologue est en cause, nous savons que Javascrip{filtering}t ou jQuery est une technique de script dynamique souvent utilisée dans le développement front-end web. Dans Javascrip{filtering}t, il existe une limitation de sécurité importante connue sous le nom de « politique de même origine ». Cette politique impose une restriction importante sur le contenu de la page à laquelle le code Javascrip{filter}t peut accéder, c’est-à-dire que Javascrip{filtering}t ne peut accéder qu’au contenu sous le même nom de domaine que le document ou le script qui le contient. Les scripts sous différents domaines ne peuvent pas s’accéder entre eux, pas même aux sous-domaines. Concernant la stratégie homologue, les lecteurs peuvent l’expliquer plus en détail sur Baidu, ce qui ne sera pas répété ici.
Mais parfois, il est inévitable de réaliser des opérations inter-domaines, et la « politique homologue » est une limitation, que devons-nous faire ? Examinons comment le JSONP inter-domaine est implémenté et discutons du principe du JSONP inter-domaine.
JSONP est mentionné ici, puis quelqu’un a demandé quelle est la différence et la différence entre lui et JSON ? Jetons un œil, l’encyclopédie Baidu donne l’explication suivante :
JSON (Javascrip{filtering}t Object Notation) est un format d’échange de données léger. Il est basé sur un sous-ensemble de Javascrip{filter}t (Standard ECMA-262 3e édition - décembre 1999). JSON utilise un format de texte totalement indépendant du langage, mais utilise aussi des habitudes similaires à la famille C (incluant C, C++, C#, Java, Javascrip, Perl, Python, etc.). Ces caractéristiques font du JSON un langage idéal pour l’échange de données. Facile à lire et à écrire par des humains, mais aussi facile à analyser et à générer par machine (transmission réseau rapide).
JSONP (JSON avec bourrage) est un « modèle d’utilisation » du JSON, qui peut être utilisé pour résoudre le problème de l’accès aux données inter-domaines dans les navigateurs grand public. En raison de la politique de même origine, les pages généralement situées sur server1.example.com ne peuvent pas communiquer avec des serveurs qui ne sont pas server1.example.com, à l’exception de l’élément <scrip{filter}t> du HTML. Grâce à cette stratégie ouverte de l’élément <scrip{filter}t>, les pages web peuvent obtenir des données JSON générées dynamiquement à partir d’autres sources, et ce schéma d’utilisation est connu sous le nom de JSONP. Les données capturées avec JSONP ne sont pas du JSON, mais un Javascrip{filter}t arbitraire, qui est exécuté avec le traducteur Javascrip{filter}t au lieu d’être analysé par l’analyseur JSON.
À ce stade, il faut comprendre que JSON est un format d’échange de données léger, comme xml, utilisé pour décrire les données entre données. JSONP est une façon d’utiliser des données JSON, et au lieu de retourner un objet JSON, c’est un script javascrip{filtering}t qui contient un objet JSON.
Alors, comment fonctionne JSONP ? Nous savons qu’en raison des limitations de la politique de même origine, XmlHttpRequest n’autorise que les requêtes de ressources provenant de la source courante (nom de domaine, protocole, port). Les requêtes inter-domaines ne sont pas possibles pour des raisons de sécurité, mais nous avons constaté que lorsque des fichiers js sont appelés sur des pages web, ils ne sont pas affectés par le cross-domain ou non, et les balises avec l’attribut « src » ont des capacités inter-domaines, telles que <scrip{filter}t>, <img>, ,<iframe>Si vous souhaitez faire une requête inter-domaine, faites-en une en utilisant la balise scrip{filter}t de html, et retournez le code script{filtering}t à exécuter dans la réponse, dans lequel vous pouvez directement utiliser le JSON pour passer l’objet javascrip{filter}t. C’est-à-dire générer des données JSON sur le serveur multi-domaine, puis les envelopper dans un script script{filtering}t en retour, ce qui dépasse les limites de la politique de la même origine et résout le problème de l’accès inter-domaine.
Voyons comment y parvenir :
Code front-end :
|
Publié sur 28/12/2015 14:22:00
|
|
|
