Politique de même origine
Dans les langages de programmation côté client, tels que JavaScript et ActionScript, la politique de même origine est un concept de sécurité très important, qui revêt une grande importance pour garantir la sécurité des données. La politique de même origine stipule que les scripts inter-domaines sont isolés. Les scripts d'un domaine ne peuvent pas accéder à la plupart des propriétés et méthodes d'un autre domaine et les exploiter. Alors, qu’est-ce qu’un même domaine et qu’est-ce qu’un domaine différent ? Lorsque deux domaines ont le même protocole (comme http), le même port (comme 80) et le même hôte (comme www.example.org), alors nous pouvons les considérer comme étant le même domaine. Par exemple, http://www.example.org/index.html et http://www.example.org/sub/index.html se trouvent dans le même domaine, tandis que http://www.example.org, https ://www Deux .example.org, http://www.example.org:8080, http://sub.example.org constitueront un inter-domaine. La politique de même origine doit également gérer certaines situations particulières, telles que la restriction des autorisations d'accès des scripts sous le protocole de fichier. Les fichiers HTML locaux sont ouverts dans le navigateur via le protocole de fichier. Si le script peut accéder à d'autres fichiers sur le disque dur via le protocole de fichier, des risques de sécurité surgiront. Actuellement, IE8 présente toujours de tels risques.
Affecté par la même politique d'origine, le partage des ressources entre domaines sera restreint. Cependant, avec la pratique des gens et les progrès des navigateurs, de nombreuses expériences précieuses ont été accumulées et accumulées dans les compétences en matière de requêtes inter-domaines. Ici, je divise le partage de ressources entre domaines en deux types, l'un est une demande de données unidirectionnelle et l'autre est une communication de messages bidirectionnelle. Ensuite, je vais énumérer quelques méthodes inter-domaines courantes. Le code source des exemples inter-domaines suivants peut être obtenu ici .
Cross-domaine unidirectionnel
JSONP
JSONP (JSON with Padding) est une méthode inter-domaines simple et efficace. La balise de script en HTML peut charger et exécuter du JavaScript à partir d'autres domaines, nous pouvons donc charger dynamiquement des ressources d'autres domaines via des balises de script. Par exemple, si je souhaite charger les données du domaine B à partir de la page pageA du domaine A, alors dans la page pageB du domaine B, je déclare les données requises par la pageA sous forme de JavaScript, puis j'utilise la balise script dans pageA pour charger la pageB, puis dans pageB Le script sera exécuté. JSONP ajoute une fonction de rappel sur cette base. Une fois la pageB chargée, la fonction définie dans la pageA sera exécutée et les données requises seront transmises à la fonction sous forme de paramètres. JSONP est facile à mettre en œuvre, mais il existe également certains risques de sécurité. Si un script tiers est exécuté à volonté, il peut falsifier le contenu de la page et intercepter des données sensibles. Mais lors du transfert de données entre parties de confiance, JSONP est un choix très approprié.
Chargeur d'URL Flash
Flash possède son propre ensemble de politiques de sécurité. Le serveur peut utiliser le fichier crossdomain.xml pour déclarer le domaine auquel les fichiers SWF sont accessibles. Il peut également utiliser l'API pour déterminer les domaines par lesquels ils peuvent être chargés. Lors de l'accès à des ressources sur plusieurs domaines, par exemple en demandant des données sur le domaine www.b.com à partir du domaine www.a.com, nous pouvons utiliser Flash pour envoyer des requêtes HTTP. Tout d'abord, modifiez le crossdomain.xml sur le domaine www.b.com (généralement stocké dans le répertoire racine, s'il n'est pas nécessaire de le créer manuellement), ajoutez www.a.com à la liste blanche. Deuxièmement, la requête HTTP est envoyée via Flash URLLoader et enfin, le résultat de la réponse est transmis à JavaScript via l'API Flash. Flash URLLoader est une solution interdomaine très courante, mais si elle doit prendre en charge iOS, cette solution ne peut rien faire.
Contrôle d'accès
Le contrôle d'accès est une méthode inter-domaines plus transcendante. Il n'est actuellement pris en charge que dans quelques navigateurs. Ces navigateurs peuvent envoyer une requête HTTP inter-domaines (Firefox, Google Chrome, etc. sont implémentés via XMLHTTPRequest, et IE8 est implémenté via XDomainRequest. ). La réponse à la demande doit inclure un en-tête de réponse HTTP Access-Control-Allow-Origin, qui déclare l'accessibilité du domaine demandé. Par exemple, www.a.com envoie une requête HTTP inter-domaines à Asset.php sous www.b.com , puis Asset.php doit ajouter l'en-tête de réponse suivant :
en-tête("Access-Control-Allow-Origin : http://www.a.com");