mode: 'no-cors'
magicamente não fará as coisas funcionarem. Na verdade, isso piora as coisas, porque um efeito que ele tem é dizer aos navegadores: "Bloqueie meu código JavaScript de front-end de examinar o conteúdo do corpo da resposta e dos cabeçalhos em todas as circunstâncias". Claro que você quase nunca quer isso.
O que acontece com solicitações de origem cruzada do JavaScript de front-end é que os navegadores, por padrão, bloqueiam o código de front-end de acessar recursos de origem cruzada. Se Access-Control-Allow-Origin
houver uma resposta, os navegadores relaxarão esse bloqueio e permitirão que seu código acesse a resposta.
Mas se um site não envia Access-Control-Allow-Origin
respostas, o código do front-end não pode acessar diretamente as respostas desse site. Em particular, você não pode corrigi-lo especificando mode: 'no-cors'
(de fato, isso garantirá que seu código de front-end não possa acessar o conteúdo da resposta).
No entanto, uma coisa que vai funcionar: se você enviar o seu pedido através de um proxy CORS , como este:
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>
Nota: se você tentar usar https://cors-anywhere.herokuapp.com, descobrir que está desativado , também poderá implantar facilmente seu próprio proxy no Heroku em literalmente apenas 2-3 minutos, com 5 comandos:
git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master
Após executar esses comandos, você terminará com seu próprio servidor CORS Anywhere em execução, por exemplo, em https://cryptic-headland-94862.herokuapp.com/ . Portanto, em vez de prefixar seu URL de solicitação https://cors-anywhere.herokuapp.com
, prefixe-o com o URL da sua própria instância; por exemplo, https://cryptic-headland-94862.herokuapp.com/https://example.com .
Eu posso atingir esse endpoint, http://catfacts-api.appspot.com/api/facts?number=99
via Postman
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Access_control_CORS explica por que, mesmo que você possa acessar a resposta com o Postman, os navegadores não permitem acessar a resposta entre origens da interface Código JavaScript em execução em um aplicativo Web, a menos que a resposta inclua um Access-Control-Allow-Origin
cabeçalho de resposta.
http://catfacts-api.appspot.com/api/facts?number=99 não tem Access-Control-Allow-Origin
cabeçalho de resposta, portanto, não há como seu código de front-end acessar a origem de resposta.
Seu navegador pode obter a resposta perfeita e você pode vê-la no Postman e até nas ferramentas do navegador - mas isso não significa que os navegadores a exponham ao seu código. Eles não vão, porque não tem Access-Control-Allow-Origin
cabeçalho de resposta. Portanto, você deve usar um proxy para obtê-lo.
O proxy faz a solicitação para esse site, obtém a resposta, adiciona o Access-Control-Allow-Origin
cabeçalho de resposta e quaisquer outros cabeçalhos CORS necessários e depois o transmite de volta ao seu código solicitante. E essa resposta com o Access-Control-Allow-Origin
cabeçalho adicionado é o que o navegador vê; portanto, o navegador permite que seu código de front-end realmente acesse a resposta.
Então, eu estou tentando passar um objeto, para o meu Fetch, que irá desativar o CORS
Você não quer fazer isso. Para ser claro, quando você diz que deseja "desativar o CORS", parece que realmente quer dizer que deseja desativar a política de mesma origem . O próprio CORS é realmente uma maneira de fazer isso - o CORS é uma maneira de afrouxar a política de mesma origem, não uma maneira de restringi-la.
De qualquer forma, é verdade que você pode - apenas no seu ambiente local - executar ações como dar sinalizadores de tempo de execução ao navegador para desativar a segurança e executar de forma insegura, ou instalar uma extensão do navegador localmente para contornar a política de mesma origem, mas tudo o que faz é mudar a situação apenas para você localmente.
Não importa o que você altere localmente, qualquer outra pessoa que tentar usar seu aplicativo ainda terá a mesma política de origem e não há como desabilitar isso para outros usuários do seu aplicativo.
É provável que você nunca queira usar mode: 'no-cors'
na prática, exceto em alguns casos limitados , e mesmo assim apenas se souber exatamente o que está fazendo e quais são os efeitos. Isso mode: 'no-cors'
ocorre porque a configuração realmente diz ao navegador: "Bloqueie meu código JavaScript de front-end de examinar o conteúdo do corpo da resposta e dos cabeçalhos em todas as circunstâncias". Na maioria dos casos, isso obviamente não é exatamente o que você deseja.
Quanto aos casos em que você gostaria de considerar o uso mode: 'no-cors'
, consulte a resposta em Quais limitações se aplicam a respostas opacas? para os detalhes. A essência disso é que os casos são:
No caso limitada quando você está usando JavaScript para fazer um recurso de outra origem o conteúdo de um <script>
, <link rel=stylesheet>
, <img>
, <video>
, <audio>
, <object>
, <embed>
, ou <iframe>
elemento (que funciona porque a incorporação de recursos de origem cruzada é permitido para aqueles) - mas por alguma razão você não deseja ou não pode fazer isso apenas fazendo com que a marcação do documento use a URL do recurso como o atributo href
ou src
do elemento.
Quando a única coisa que você deseja fazer com um recurso é armazená-lo em cache. Como mencionado na resposta em Quais limitações se aplicam a respostas opacas? , na prática, o cenário a que se aplica é quando você está usando Service Workers. Nesse caso, a API relevante é a API de armazenamento em cache .
Mas mesmo nesses casos limitados, há algumas dicas importantes a serem observadas; veja a resposta em Quais limitações se aplicam a respostas opacas? para os detalhes.
Eu também tentei passar o objeto { mode: 'opaque'}
Não há mode: 'opaque'
modo de solicitação - opaque
é apenas uma propriedade da resposta e os navegadores definem essa propriedade opaca nas respostas de solicitações enviadas com o no-cors
modo.
Mas, aliás, a palavra opaco é um sinal bastante explícito sobre a natureza da resposta com a qual você termina: "opaco" significa que você não pode vê-lo.
cors-anywhere
solução alternativa para casos de uso simples que não sejam de prod (como buscar alguns dados publicamente disponíveis). Essa resposta confirma minha suspeita de que issono-cors
não é comum porque o seu OpaqueResponse não é muito útil; ie "casos muito limitados"; alguém pode me explicar exemplos ondeno-cors
é útil?