Requête d'origine croisée bloquée : comprendre CORS et la syntaxe de récupération
Dans le domaine des requêtes d'origine croisée, où les navigateurs empêchent les scripts d'accéder ressources d'origines différentes, pour des raisons de sécurité, les développeurs rencontrent souvent le redoutable "Aucun en-tête 'Access-Control-Allow-Origin' n'est présent sur la ressource demandée" erreur. Pour résoudre ce problème, il est essentiel de comprendre le concept de CORS (Cross-Origin Resource Sharing) et ses implications pour notre syntaxe Fetch.
L'énigme CORS
CORS est un mécanisme appliqué par le navigateur qui protège les utilisateurs contre le code malveillant exécuté sur d'autres sites Web et empêchant l'accès aux informations sensibles stockées localement. Par défaut, les navigateurs empêchent les requêtes d'origine croisée provenant du code JavaScript, mais ils offrent un moyen d'assouplir cette restriction en ajoutant un en-tête Access-Control-Allow-Origin à la réponse du serveur. Cet en-tête précise quelles origines sont autorisées à accéder à la ressource.
Décodage de l'erreur de syntaxe
Dans l'extrait de code spécifié, le développeur tente d'utiliser le mode : 'non -cors dans l'objet Fetch pour désactiver CORS. Cependant, cette approche est fondamentalement erronée car mode: 'no-cors' demande effectivement au navigateur de bloquer tout accès aux en-têtes et au corps de la réponse. Par conséquent, même si le serveur envoyait une réponse avec un en-tête Access-Control-Allow-Origin approprié, elle serait ignorée par le navigateur, ce qui entraînerait une erreur de syntaxe dans l'appel fetch.
Les pièges du mode : 'no-cors'
L'utilisation du mode : 'no-cors' n'est généralement pas recommandée, car elle peut créer des limitations inattendues dans la gestion de la réponse par le navigateur. Plus précisément, ce mode empêche le navigateur de révéler le contenu et les en-têtes de la réponse, ce qui est souvent nécessaire au bon traitement des données dans le code JavaScript.
La solution proxy
Pour contourner les restrictions CORS sans compromettre la sécurité du navigateur, nous pouvons utiliser un proxy CORS. Un proxy agit en tant qu'intermédiaire, effectuant la demande d'origine croisée au nom du client et ajoutant les en-têtes CORS nécessaires à la réponse avant de la renvoyer au demandeur d'origine.
Postman Versus Browsers
Il est crucial de noter que même si Postman, un outil de test de requêtes HTTP populaire, n'applique pas les restrictions CORS par défaut, les navigateurs le font. Cette différence vient du fait que Postman est un outil de débogage destiné à tester les points de terminaison de l'API, tandis que les navigateurs donnent la priorité à la sécurité des utilisateurs.
Résumé
En conclusion, le mode : « no-cors » ne doit être utilisé que dans des circonstances limitées où des réponses opaques sont souhaitées. Les proxys CORS offrent une solution précieuse pour les requêtes d'origine croisée tout en préservant la sécurité du navigateur. Comprendre les subtilités de CORS et appliquer les techniques appropriées est essentiel pour permettre une communication sécurisée et transparente entre les sites Web et leurs ressources.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!