introduire
La politique de même origine du navigateur fait référence à une politique qui limite les réponses aux demandes dont l'adresse de demande est incompatible avec la source de la demande, c'est-à-dire si la réponse du serveur à une demande d'origine croisée n'est pas conforme à la spécification de la politique de même origine du navigateur, alors Le navigateur n'affichera pas le contenu de la réponse.
Tant que l'un des protocoles , hôtes et numéros de port de deux URL est différent, ils sont considérés comme des sources différentes.
Cela implique un point très important, c'est-à-dire que la requête cross-origin que nous avons envoyée n'a pas atteint le serveur, mais le navigateur décidera d'afficher ou non le contenu de la réponse en fonction des champs pertinents de l'en-tête de réponse renvoyé par le serveur .
Pour les champs liés à CORS , veuillez vous référer à cet article Cross-Origin Resource Sharing CORS Details Explanation , qui présente en détail comment les champs liés à CORS affectent le succès des requêtes CORS dans les navigateurs.
Il convient de noter que pour les méthodes GET , POST et HEAD , même si Access-Control-Allow-Methods dans l'en-tête de réponse ne les inclut pas, tant que le champ Access-Control-Allow-Origin correspond à l'origine du demande , il est également considéré comme un budget La demande de vérification a réussi. On peut voir que les trois valeurs de GET , POST et HEAD sont les valeurs par défaut de Access-Control-Allow-Methods , et la définition du champ Access-Control-Allow-Methods consiste simplement à ajouter plus de méthodes autorisées .
Les navigateurs divisent ces requêtes cross-origin (CORS) en deux catégories : les requêtes simples et les requêtes complexes .
demande simple
Pour la définition des requêtes simples, reportez-vous au document MDN , et celles qui ne répondent pas aux exigences sont considérées comme des requêtes complexes.
la différence
La différence entre les deux est que la demande de contrôle en amont (preflight) ne sera pas envoyée avant que la demande complexe ne soit envoyée . Le but de la demande de contrôle en amont est que bien que le navigateur ne le laisse pas réussir pour certains CORS, il a en effet demandé au serveur, ce qui peut entraîner une demande CORS supprimée au serveur s'il n'y a pas de demande de contrôle en amont, et Affecté avec succès, mais le navigateur ne renverra pas le résultat de la réponse en raison de la politique de même origine. Par conséquent, avant d'envoyer le CORS réel , le navigateur général enverra une demande de pré-vérification pour demander si le serveur autorise l'origine croisée, sinon, il n'enverra pas la demande réelle, afin d'éviter d'affecter les données du serveur.
Il est à noter que dans la dernière version de Chrome, même une simple requête, si l'adresse à laquelle elle accède est un réseau privé, elle va d'abord initier une requête en amont, référez-vous à accès réseau privé : introduisez une requête en amont .
Le document spécifie quand accéder à un réseau privé, tel que l'accès à un LAN dans un réseau public, ou l'accès à un réseau local (localhost) dans un LAN.
Quant à savoir pourquoi l'accès au réseau privé doit également envoyer une demande de contrôle en amont, c'est parce que dans ce cas, des attaques de rebinding DNS peuvent se produire . Cet article est une bonne introduction au principe des attaques DNS rebinding : Explication détaillée des attaques DNS rebinding .
Mais en fait, si vous y réfléchissez, vous constaterez que la demande de contrôle en amont semble inutile. Parce que le serveur peut complètement juger s'il doit répondre à la demande en fonction de la source de la demande CORS. Si la demande ne répond pas aux exigences, elle peut être rejetée directement. Il n'est pas nécessaire que le navigateur envoie une demande de pré-vérification d'abord. C'est en effet le cas. Pour les serveurs qui ont déjà une protection contre CORS , la demande de contrôle en amont est en effet redondante, mais la politique de même origine des navigateurs est apparue plus tard, et les serveurs avant cela n'ont pas empêché CORS, et ils n'ont pas délibérément fait la distinction entre La source de la demande, mais répondra à tous, alors cela provoquera effectivement la situation mentionnée ci-dessus, donc le navigateur impose diverses restrictions pour protéger ce type de serveur. C'est pourquoi il est dit que la politique de même origine du navigateur est un gentleman's agreement, qui ne prend effet que du côté du navigateur.
Vous pouvez jeter un œil à ce post : Pourquoi introduire une demande de contrôle en amont ?
Interdomaine dans les balises HTML
De nombreuses balises HTML peuvent envoyer des requêtes, telles que les formulaires, les balises a, les balises img, etc., mais certaines ne seront pas restreintes, comme JSONP , qui utilise des balises de script pour ne pas être affectées par les politiques d'origine croisée.
substance
Je pense que la réponse à cette question est très bonne : pourquoi n'y a-t-il pas de problème inter-domaines dans la soumission de formulaire, mais il y a un problème inter-domaines dans la soumission ajax ?
Le JS d'un nom de domaine ne peut pas lire le contenu d'un autre nom de domaine sans autorisation. Mais les navigateurs ne vous empêchent pas d'envoyer des requêtes vers un autre nom de domaine.