Traitement inter-domaines
Inter-domaine : restrictions du navigateur sur la politique de même origine de JavaScript.
Le but de la politique de même origine est d'assurer la sécurité des informations des utilisateurs et d'empêcher les sites Web malveillants de voler des données. Imaginez une situation : le site A est une banque. Une fois l'utilisateur connecté, le site A installe un cookie sur la machine de l'utilisateur, qui contient certaines informations privées (telles que le montant total du dépôt). Une fois que l'utilisateur a quitté le site Web A, il visite à nouveau le site Web B. S'il n'y a aucune restriction d'origine, le site Web B peut lire les cookies du site Web A et les informations privées seront divulguées. Ce qui est encore plus effrayant, c'est que les cookies sont souvent utilisés pour enregistrer le statut de connexion de l'utilisateur. Si l'utilisateur ne se déconnecte pas, d'autres sites Web peuvent usurper l'identité de l'utilisateur et faire ce qu'ils veulent.
Les situations suivantes sont toutes inter-domaines :
| Explication de la raison inter-domaines | Exemple |
|---|---|
| Les noms de domaine sont différents | www.jd.com et www.taobao.com |
| Même nom de domaine mais ports différents | www.jd.com:8080 et www.jd.com:8081 |
| Les noms de domaine de deuxième niveau sont différents | item.jd.com et miaosha.jd.com |
Si le nom de domaine et le port sont identiques mais que les chemins de requête sont différents, il ne s'agit pas d'un inter-domaine, comme :
www.jd.com/item
www.jd.com/goods
http et https sont également inter-domaines
Et nous venons d'accéder à localhost : 8888 à partir de localhost : 1000. Il s'agit d'un port et d'un inter-domaine différent.
Pourquoi y a-t-il des problèmes inter-domaines ?
Les problèmes inter-domaines ne surviennent pas toujours.
Parce que le problème inter-domaines est une restriction de sécurité du navigateur pour les requêtes ajax : une requête ajax initiée par une page ne peut être que le même chemin que le nom de domaine de la page actuelle, ce qui peut empêcher efficacement les attaques inter-sites.
Par conséquent : les problèmes inter-domaines sont une limitation d’Ajax.
Mais cela entraîne des inconvénients pour notre développement, et dans l'environnement de production actuel, il y aura certainement de nombreux serveurs qui interagiront les uns avec les autres, et les adresses et les ports pourront être différents.
Solution aux problèmes inter-domaines
Il existe actuellement trois solutions interdomaines couramment utilisées :
-Jsonp
La première solution peut être mise en œuvre en utilisant le principe inter-domaines à l'aide de balises de script.
https://www.w3cschool.cn/json/json-jsonp.html
limite:
- Nécessite une assistance technique
- Seules les requêtes GET peuvent être lancées
principe:
Jsonp est en fait une solution inter-domaines. Il n'est pas possible pour JS de demander des données sur plusieurs domaines, mais il est possible pour JS de demander des scripts JS sur plusieurs domaines. Vous pouvez encapsuler les données dans une instruction js et effectuer un appel de méthode. Ce script peut être obtenu en demandant un script js inter-domaines. Le script js sera exécuté immédiatement après l'avoir obtenu. Les données peuvent être transmises en tant que paramètres aux méthodes. Vous pouvez obtenir les données. Cela résout les problèmes inter-domaines.
- proxy inverse nginx
L'idée est la suivante : utilisez nginx pour rendre le proxy inverse interdomaine non interdomaine et prendre en charge diverses méthodes de requête.
Inconvénients : une configuration supplémentaire est requise dans nginx et la sémantique n'est pas claire
Le nom de domaine du serveur frontal est : fe.server.com. Le nom de domaine du service back-end est : dev.server.com. Désormais, lorsque j'initie une requête à dev.server.com depuis fe.server .com, il y aura certainement une demande inter-domaines. Il ne nous reste plus qu'à démarrer un serveur nginx, définir server_name sur fe.server.com, puis définir l'emplacement correspondant pour intercepter les requêtes inter-domaines depuis le front-end, et enfin renvoyer la requête par proxy à dev.server.com. Par exemple, la configuration suivante : server { listening 80; server_name fe.server.com; location / { proxy_pass dev.server.com; }} Cela peut parfaitement contourner la politique de même origine du navigateur. L'accès de fe.server.com au fe.server.com de nginx est un accès de même origine, et la requête transmise par nginx au serveur ne déclenchera pas la politique de même origine du navigateur.
- CORS
Solution de requêtes inter-domaines standardisée, sûre et fiable.
Avantage:
- Contrôler si le cross-domain est autorisé côté serveur, règles personnalisables
-Supporte diverses méthodes de demande
défaut:
- Générera des demandes supplémentaires (contrôle en amont)
Nous utiliserons ici la solution interdomaine de cors.
qu'est-ce que le cors
CORS est une norme du W3C, dont le nom complet est « Cross-origin Resource Sharing ».
Il permet au navigateur d'émettre des requêtes XMLHttpRequest vers des serveurs d'origines croisées, surmontant ainsi la limitation selon laquelle AJAX ne peut être utilisé qu'à partir de la même origine.
XMLHttpRequest : l'objet principal d'Ajax
CORS nécessite la prise en charge du navigateur et du serveur. Actuellement, tous les navigateurs prennent en charge cette fonction et le navigateur IE ne peut pas être inférieur à IE10.
- Côté navigateur : pas besoin de réfléchir
Actuellement, tous les navigateurs prennent en charge cette fonction (non disponible sous IE10). L'ensemble du processus de communication CORS est automatiquement complété par le navigateur et ne nécessite pas la participation de l'utilisateur.
- Côté serveur : effectuez les réglages pertinents
La communication CORS n'est pas différente de celle d'AJAX, vous n'avez donc pas besoin de modifier votre logique métier précédente. Cependant, le navigateur contiendra certaines informations d'en-tête dans la requête. Nous devons les utiliser pour déterminer si elle est autorisée à traverser le domaine, puis ajouter des informations à l'en-tête de réponse. Cela se fait généralement via un filtre.
Le principe est un peu compliqué
Demande de contrôle en amont
Les requêtes inter-domaines ajouteront une requête de requête HTTP avant la communication formelle, appelée requête de « contrôle en amont ».
Le navigateur demande d'abord au serveur si le nom de domaine de la page Web actuelle figure dans la liste des autorisations du serveur et quels verbes HTTP et champs d'informations d'en-tête peuvent être utilisés. Ce n'est que lorsqu'une réponse positive est reçue que le navigateur émettra une requête XMLHttpRequest formelle, sinon une erreur sera signalée.
Un exemple de demande de « contrôle en amont » :
OPTIONS /cors HTTP/1.1
Origine : http://localhost:8888
Méthode de demande de contrôle d'accès : GET
En-têtes de demande de contrôle d'accès : X-Custom-Header
Agent utilisateur : Mozilla/5.0…
- Origine : Il indiquera à quel domaine appartient la requête en cours (protocole + nom de domaine + port). Le service décidera d'autoriser ou non le cross-domain en fonction de cette valeur.
- Access-Control-Request-Method : la méthode de requête qui sera utilisée ensuite, telle que PUT
- Access-Control-Request-Headers : informations d'en-tête supplémentaires utilisées
Réponse à la demande de contrôle en amont
Le service reçoit la demande de contrôle en amont et émettra une réponse si l'autorisation est inter-domaine :
HTTP/1.1 200 OK
Date : lundi 1er décembre 2008 01:15:39 GMT
Serveur : Apache/2.0.61 (Unix)
Contrôle d'accès-Autoriser-Origin : http://localhost:8888
Access-Control-Allow-Credentials : vrai
Méthodes d'autorisation de contrôle d'accès : GET, POST, PUT
En-têtes d'autorisation de contrôle d'accès : X-Custom-Header
Contrôle d'accès-Âge maximum : 1728000
Type de contenu : texte/html ; jeu de caractères = utf-8
Encodage du contenu : gzip
Longueur du contenu : 0
Keep-Alive : délai d'attente = 2, maximum = 100
Connexion : Keep-Alive
Type de contenu : texte/plain
Si le serveur autorise le cross-domain, les informations suivantes doivent être contenues dans l'en-tête de réponse renvoyé :
- Access-Control-Allow-Origin : Le domaine acceptable est un nom de domaine spécifique ou * (représentant n'importe quel nom de domaine)
- Access-Control-Allow-Credentials : s'il faut autoriser le transport de cookies. Par défaut, cors ne transportera pas de cookies à moins que cette valeur ne soit vraie.
- Access-Control-Allow-Methods : Autoriser les méthodes d'accès
- Access-Control-Allow-Headers : en-têtes autorisés à être transportés
- Access-Control-Max-Age : La période de validité de cette autorisation, en secondes. Les requêtes Ajax avant expiration n'ont pas besoin d'être pré-vérifiées à nouveau.
À propos des cookies :
Pour utiliser les cookies, les conditions suivantes doivent être remplies :
- L'en-tête de réponse du service doit contenir Access-Control-Allow-Credentials et être vrai.
- Lorsque le navigateur lance ajax, vous devez spécifier withCredentials comme true