mode: 'no-cors'
ne fera pas fonctionner les choses comme par magie. En fait, cela aggrave les choses, car l'un de ses effets est de dire aux navigateurs: "Empêchez mon code JavaScript frontal de consulter le contenu du corps de la réponse et des en-têtes en toutes circonstances." Bien sûr, vous ne le voulez presque jamais.
Ce qui se passe avec les requêtes cross-origin de JavaScript frontend, c'est que les navigateurs bloquent par défaut le code frontend pour accéder aux ressources cross-origin. S'il Access-Control-Allow-Origin
y a une réponse, les navigateurs relâcheront ce blocage et permettront à votre code d'accéder à la réponse.
Mais si un site envoie non Access-Control-Allow-Origin
dans ses réponses, votre code frontend ne peut pas accéder directement aux réponses de ce site. En particulier, vous ne pouvez pas le résoudre en spécifiant mode: 'no-cors'
(en fait, cela garantira votre code frontend ne pourra pas accéder au contenu de la réponse).
Cependant, une chose qui va travailler: si vous envoyez votre demande par l' intermédiaire d' un proxy CORS , comme ceci:
var proxyUrl = 'https://cors-anywhere.herokuapp.com/',
targetUrl = 'http://catfacts-api.appspot.com/api/facts?number=99'
fetch(proxyUrl + targetUrl)
.then(blob => blob.json())
.then(data => {
console.table(data);
document.querySelector("pre").innerHTML = JSON.stringify(data, null, 2);
return data;
})
.catch(e => {
console.log(e);
return e;
});
<pre></pre>
Remarque: si lorsque vous essayez d'utiliser https://cors-anywhere.herokuapp.com, vous trouvez qu'il est en panne , vous pouvez également facilement déployer votre propre proxy sur Heroku en seulement 2-3 minutes, avec 5 commandes:
git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master
Après avoir exécuté ces commandes, vous vous retrouverez avec votre propre serveur CORS Anywhere fonctionnant à, par exemple, https://cryptic-headland-94862.herokuapp.com/ . Ainsi, plutôt que de préfixer votre URL de requête avec https://cors-anywhere.herokuapp.com
, préfixez-la plutôt avec l'URL de votre propre instance; par exemple, https://cryptic-headland-94862.herokuapp.com/https://example.com .
Je peux atteindre ce point de terminaison, http://catfacts-api.appspot.com/api/facts?number=99
via Postman
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS explique pourquoi même si vous pouvez accéder à la réponse avec Postman, les navigateurs ne vous permettront pas d'accéder à l'origine croisée de la réponse depuis le frontend Code JavaScript exécuté dans une application Web, sauf si la réponse inclut un en- Access-Control-Allow-Origin
tête de réponse.
http://catfacts-api.appspot.com/api/facts?number=99 n'a pasAccess-Control-Allow-Origin
tête de réponse, il n'y a donc aucun moyen pour votre code frontal d'accéder à l'origine croisée de la réponse.
Votre navigateur peut obtenir la réponse correctement et vous pouvez la voir dans Postman et même dans les outils de développement du navigateur - mais cela ne signifie pas que les navigateurs l'exposeront à votre code. Ils ne le feront pas, car il n'a pas d'en- Access-Control-Allow-Origin
tête de réponse. Vous devez donc utiliser à la place un proxy pour l'obtenir.
Le proxy fait la demande à ce site, obtient la réponse, ajoute l'en- Access-Control-Allow-Origin
tête de réponse et tous les autres en-têtes CORS nécessaires, puis le renvoie à votre code de demande. Et cette réponse avec l'en- Access-Control-Allow-Origin
tête ajouté est ce que le navigateur voit, de sorte que le navigateur laisse votre code frontal accéder réellement à la réponse.
J'essaye donc de passer un objet, à mon Fetch qui désactivera CORS
Tu ne veux pas faire ça. Pour être clair, lorsque vous dites que vous voulez «désactiver CORS», il semble que vous vouliez vraiment désactiver la politique de même origine . CORS lui-même est en fait un moyen d'y parvenir - CORS est un moyen d'assouplir la politique de même origine, pas un moyen de la restreindre.
Mais de toute façon, il est vrai que vous pouvez - dans votre environnement local seulement - faire des choses comme donner des indicateurs d'exécution à votre navigateur pour désactiver la sécurité et s'exécuter de manière non sécurisée, ou vous pouvez installer une extension de navigateur localement pour contourner la politique de même origine, mais tout cela fait est de changer la situation juste pour vous localement.
Peu importe ce que vous modifiez localement, toute autre personne qui essaiera d'utiliser votre application continuera de se heurter à la politique de même origine, et vous ne pouvez en aucun cas la désactiver pour les autres utilisateurs de votre application.
Vous ne voudrez probablement jamais l'utiliser mode: 'no-cors'
en pratique, sauf dans quelques cas limités , et même dans ce cas uniquement si vous savez exactement ce que vous faites et quels sont les effets. C'est parce que ce que le paramètre mode: 'no-cors'
dit réellement au navigateur est: "Empêchez mon code JavaScript frontal de regarder dans le contenu du corps de la réponse et des en-têtes en toutes circonstances." Dans la plupart des cas, ce n'est évidemment pas ce que vous voulez.
En ce qui concerne les cas où vous voudriez envisager d'utiliser mode: 'no-cors'
, consultez la réponse à Quelles limites s'appliquent aux réponses opaques? pour les détails. L'essentiel est que les cas sont:
Dans le cas limité où vous utilisez JavaScript pour mettre du contenu d'une autre origine dans un <script>
,<link rel=stylesheet>
, <img>
, <video>
, <audio>
, <object>
, <embed>
ou <iframe>
élément (qui fonctionne parce que l' incorporation des ressources Croiser d'origine est autorisée pour les) - mais pour une raison quelconque , vous n » Vous voulez ou ne pouvez pas faire cela simplement en demandant au balisage du document d'utiliser l'URL de la ressource comme attribut href
ou src
pour l'élément.
Lorsque la seule chose que vous voulez faire avec une ressource est de la mettre en cache. Comme évoqué dans la réponse Quelles limites s'appliquent aux réponses opaques? , en pratique, le scénario qui s'applique est lorsque vous utilisez des Service Workers, auquel cas l'API pertinente est l' API Cache Storage .
Mais même dans ces cas limités, il y a quelques pièges importants à prendre en compte; voir la réponse à Quelles limites s'appliquent aux réponses opaques? pour les détails.
J'ai aussi essayé de passer dans l'objet { mode: 'opaque'}
Il n'y a pas de mode: 'opaque'
mode de demande - il opaque
s'agit plutôt d'une propriété de la réponse , et les navigateurs définissent cette propriété opaque sur les réponses des demandes envoyées avec le no-cors
mode.
Mais accessoirement le mot opaque est un signal assez explicite sur la nature de la réponse que vous obtenez: «opaque» signifie que vous ne pouvez pas le voir.
cors-anywhere
solution de contournement pour les cas d'utilisation simples non-prod (c'est-à-dire la récupération de données accessibles au public). Cette réponse confirme mon soupçon quino-cors
n'est pas commun car son OpaqueResponse n'est pas très utile; c'est-à-dire "cas très limités"; quelqu'un peut-il m'expliquer des exemples où celano-cors
est utile?