mode: 'no-cors'
mágicamente no hará que las cosas funcionen. De hecho, empeora las cosas, porque un efecto que tiene es decirle a los navegadores: "Bloquee el código JavaScript de mi interfaz para que no vea el contenido del cuerpo de respuesta y los encabezados en todas las circunstancias". Por supuesto, casi nunca quieres eso.
Lo que sucede con las solicitudes de origen cruzado de JavaScript frontend es que los navegadores de forma predeterminada impiden que el código frontend acceda a los recursos de origen cruzado. Si Access-Control-Allow-Origin
hay una respuesta, los navegadores relajarán ese bloqueo y permitirán que su código acceda a la respuesta.
Pero si un sitio no envía Access-Control-Allow-Origin
sus respuestas, su código de interfaz no puede acceder directamente a las respuestas de ese sitio. En particular, no puede solucionarlo especificando mode: 'no-cors'
(de hecho, eso asegurará que su código de interfaz no pueda acceder al contenido de la respuesta).
Sin embargo, una cosa que va a trabajar: si envía su solicitud a través de un proxy CORS , así:
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: si cuando intenta utilizar https://cors-anywhere.herokuapp.com, encuentra que está inactivo , también puede implementar fácilmente su propio proxy en Heroku en literalmente solo 2-3 minutos, con 5 comandos:
git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master
Después de ejecutar esos comandos, terminará con su propio servidor CORS Anywhere ejecutándose en, por ejemplo, https://cryptic-headland-94862.herokuapp.com/ . Entonces, en lugar de prefijar su URL de solicitud con https://cors-anywhere.herokuapp.com
, prefije en su lugar con la URL de su propia instancia; por ejemplo, https://cryptic-headland-94862.herokuapp.com/https://example.com .
Puedo alcanzar este punto final, a http://catfacts-api.appspot.com/api/facts?number=99
través de Postman
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS explica por qué, aunque puede acceder a la respuesta con Postman, los navegadores no le permitirán acceder a la respuesta de origen cruzado desde la interfaz Código JavaScript que se ejecuta en una aplicación web a menos que la respuesta incluya un Access-Control-Allow-Origin
encabezado de respuesta.
http://catfacts-api.appspot.com/api/facts?number=99 no tiene Access-Control-Allow-Origin
encabezado de respuesta, por lo que no hay forma de que su código de interfaz pueda acceder al origen cruzado de la respuesta.
Su navegador puede obtener una buena respuesta y puede verla en Postman e incluso en las herramientas del navegador, pero eso no significa que los navegadores lo expongan a su código. No lo harán, porque no tiene Access-Control-Allow-Origin
encabezado de respuesta. Por lo tanto, debe usar un proxy para obtenerlo.
El proxy realiza la solicitud a ese sitio, obtiene la respuesta, agrega el Access-Control-Allow-Origin
encabezado de respuesta y cualquier otro encabezado CORS necesario, luego lo devuelve a su código de solicitud. Y esa respuesta con el Access-Control-Allow-Origin
encabezado agregado es lo que ve el navegador, por lo que permite que el código de la interfaz acceda realmente a la respuesta.
Así que estoy tratando de pasar un objeto a mi Fetch que deshabilitará CORS
No quieres hacer eso. Para ser claros, cuando dice que desea "deshabilitar CORS", parece que realmente quiere decir que desea deshabilitar la política del mismo origen . CORS en sí mismo es en realidad una forma de hacerlo: CORS es una forma de aflojar la política del mismo origen, no una forma de restringirla.
Pero de todos modos, es cierto que puede, solo en su entorno local, hacer cosas como dar banderas de tiempo de ejecución de su navegador para deshabilitar la seguridad y ejecutar de forma insegura, o puede instalar una extensión de navegador localmente para evitar la política del mismo origen, pero todo eso es cambiar la situación solo para usted localmente.
No importa lo que cambie localmente, cualquier otra persona que intente usar su aplicación seguirá cumpliendo con la política del mismo origen, y no hay forma de que pueda deshabilitarla para otros usuarios de su aplicación.
Lo más probable es que nunca quieras usarlo mode: 'no-cors'
en la práctica, excepto en algunos casos limitados , e incluso si solo sabes exactamente lo que estás haciendo y cuáles son los efectos. Esto se debe a que lo que la configuración mode: 'no-cors'
realmente le dice al navegador es: "Bloquee mi código JavaScript frontend para que no investigue el contenido del cuerpo de respuesta y los encabezados en todas las circunstancias". En la mayoría de los casos, eso obviamente no es lo que quieres.
En cuanto a los casos en los que podría desear considerar el uso mode: 'no-cors'
, véase la respuesta a ¿Qué limitaciones se aplican a las respuestas opacas? para los detalles La esencia de esto es que los casos son:
En el caso limitado cuando se está utilizando JavaScript para hacer un recurso de otro origen del contenido de una <script>
, <link rel=stylesheet>
, <img>
, <video>
, <audio>
, <object>
, <embed>
, o <iframe>
elemento (que funciona porque la incorporación de los recursos de origen cruzado está permitido para aquellos) - pero por alguna razón no desea o no puede hacerlo simplemente haciendo que el marcado del documento use la URL del recurso como el atributo href
o src
para el elemento.
Cuando lo único que desea hacer con un recurso es almacenarlo en caché. Como se aludió en la respuesta en ¿Qué limitaciones se aplican a las respuestas opacas? , en la práctica, el escenario que se aplica es cuando usa Service Workers, en cuyo caso la API relevante es la API de almacenamiento en caché .
Pero incluso en esos casos limitados, hay algunas trampas importantes a tener en cuenta; vea la respuesta en ¿Qué limitaciones se aplican a las respuestas opacas? para los detalles
También he tratado de pasar el objeto { mode: 'opaque'}
No hay mode: 'opaque'
modo de solicitud; en opaque
cambio, es solo una propiedad de la respuesta , y los navegadores configuran esa propiedad opaca en las respuestas de las solicitudes enviadas con el no-cors
modo.
Pero, por cierto, la palabra opaco es una señal bastante explícita sobre la naturaleza de la respuesta con la que termina: "opaco" significa que no puede verla.
cors-anywhere
solución para casos de uso simples no relacionados con productos (es decir, obtener algunos datos disponibles públicamente). Esta respuesta confirma mi sospecha de queno-cors
no es común porque su respuesta opaca no es muy útil; es decir, "casos muy limitados"; ¿Alguien puede explicarme ejemplos dondeno-cors
es útil?