javascript - node - install cors angular

XMLHttpRequest no puede cargar el encabezado XXX No ''Access-Control-Allow-Origin''

Question

tl; dr; Sobre la misma política de origen

Tengo un proceso Grunt que inicia una instancia del servidor express.js. Esto estaba funcionando absolutamente bien hasta ahora cuando comenzó a servir una página en blanco con la siguiente aparición en el registro de errores en la consola del desarrollador en Chrome (última versión):

XMLHttpRequest no puede cargar https://www.example.com/ No hay encabezado ''Access-Control-Allow-Origin'' en el recurso solicitado. El origen '' http: // localhost: 4300 '' no tiene acceso permitido.

¿Qué me impide acceder a la página?

Answer 1

Sobre la misma política de origen

Esta es la misma política de origen . Es una característica de seguridad implementada por los navegadores.

Su caso particular muestra cómo se implementa para XMLHttpRequest (y obtendrá resultados idénticos si usa fetch), pero también se aplica a otras cosas (como imágenes cargadas en un <canvas> o documentos cargados en un <iframe> ), solo con implementaciones ligeramente diferentes.

(Curiosamente, también se aplica a las fuentes CSS, pero eso se debe a que las fundiciones encontradas insistieron en DRM y no por los problemas de seguridad que generalmente cubre la Política del mismo origen).

El escenario estándar que demuestra la necesidad del SOP se puede demostrar con tres caracteres :

• Alice es una persona con un navegador web
• Bob ejecuta un sitio web ( https://www.[website].com/ en su ejemplo)
• Mallory ejecuta un sitio web ( http://localhost:4300 en su ejemplo)

Alice ha iniciado sesión en el sitio de Bob y tiene algunos datos confidenciales allí. Quizás sea una intranet de la empresa (accesible solo para los navegadores en la LAN), o su banca en línea (accesible solo con una cookie que obtiene después de ingresar un nombre de usuario y contraseña).

Alice visita el sitio web de Mallory que tiene JavaScript que hace que el navegador de Alice haga una solicitud HTTP al sitio web de Bob (desde su dirección IP con sus cookies, etc.). Esto podría ser tan simple como usar XMLHttpRequest y leer el responseText .

La Política del mismo origen del navegador evita que JavaScript lea los datos devueltos por el sitio web de Bob (a los que Bob y Alice no quieren que acceda Mallory). (Tenga en cuenta que puede, por ejemplo, mostrar una imagen usando un elemento <img> todos los orígenes porque el contenido de la imagen no está expuesto a JavaScript (o Mallory) ... a menos que arroje un lienzo a la mezcla, en cuyo caso generará un error de violación del mismo origen).

Por qué se aplica la misma política de origen cuando no cree que debería

Para cualquier URL dada es posible que no se necesite el SOP. Un par de escenarios comunes donde este es el caso son:

• Alice, Bob y Mallory son la misma persona.
• Bob está proporcionando información completamente pública

... pero el navegador no tiene forma de saber si alguna de las anteriores es verdadera, por lo que la confianza no es automática y se aplica el SOP. El permiso debe otorgarse explícitamente antes de que el navegador entregue los datos que se le dieron a un sitio web diferente.

Por qué la Política de mismo origen solo se aplica a JavaScript en una página web

Las extensiones del navegador, la pestaña Red en herramientas de desarrollo del navegador y aplicaciones como Postman son software instalado. No están pasando datos de un sitio web al JavaScript que pertenece a un sitio web diferente solo porque usted visitó ese sitio web diferente . La instalación del software generalmente requiere una elección más consciente.

No hay un tercero (Mallory) que se considere un riesgo.

¿Por qué puede mostrar datos en la página sin leerlos con JS?

Hay una serie de circunstancias en las que el sitio de Mallory puede hacer que un navegador obtenga datos de un tercero y los muestre (por ejemplo, agregando un elemento <img> para mostrar una imagen). Sin embargo, no es posible que el JavaScript de Mallory lea los datos en ese recurso, solo el navegador de Alice y el servidor de Bob pueden hacerlo, por lo que aún es seguro.

CORS

El encabezado Access-Control-Allow-Origin mencionado en el mensaje de error es parte del estándar CORS que le permite a Bob otorgar explícitamente permiso al sitio de Mallory para acceder a los datos a través del navegador de Alice.

Una implementación básica solo incluiría:

Access-Control-Allow-Origin: *

... para permitir que cualquier sitio web lea los datos.

Access-Control-Allow-Origin: http://example.com/

… Permitiría que solo un sitio específico acceda a él, y usted puede generarlo dinámicamente en función del encabezado de solicitud de Origin para permitir que múltiples, pero no todos, los sitios accedan a él.

Los detalles de cómo configurar ese encabezado de respuesta dependen del servidor HTTP de Bob y / o del lenguaje de programación del lado del servidor. Hay una colección de guías para varias configuraciones comunes que pueden ayudar.

NB: Algunas solicitudes son complejas y envían una solicitud de OPCIONES de preflight previa a la que el servidor tendrá que responder antes de que el navegador envíe GET / POST / PUT / Cualquier solicitud que el JS quiera hacer. Las implementaciones de CORS que solo agregan Access-Control-Allow-Origin a URL específicas a menudo se tropiezan con esto.

Obviamente, otorgar permiso a través de CORS es algo que Bob solo haría solo si:

• Los datos no eran privados o
• Mallory era de confianza

Si también es Bob en este escenario, los detalles de cómo agregar encabezados de permisos CORS dependerán de alguna combinación de su elección de software de servidor HTTP y qué idioma está utilizando para la programación del lado del servidor (si corresponde).

Mallory no puede agregar este encabezado porque tiene que obtener el permiso del sitio de Bob y sería una tontería (hasta el punto de inutilizar el SOP) para que ella pueda otorgarse permiso.

Mensajes de error que mencionan "Respuesta para verificación previa"

Algunas solicitudes de origen cruzado se preflight .

Esto sucede cuando (más o menos) intenta hacer una solicitud de origen cruzado que:

• Incluye credenciales como cookies
• No se pudo generar con un formulario HTML normal (p. Ej., Tiene encabezados personalizados o un Tipo de contenido que no puede usar en el tipo de enctype ).

Si está haciendo correctamente algo que necesita una verificación previa

En estos casos, el resto de esta respuesta aún se aplica, pero también debe asegurarse de que el servidor pueda escuchar la solicitud de verificación previa (que serán OPTIONS (y no GET , POST o lo que sea que esté tratando de enviar) y responder a ella con el encabezado derecho Access-Control-Allow-Origin pero también Access-Control-Allow-Methods y Access-Control-Allow-Headers para permitir sus métodos o encabezados HTTP específicos.

Si está disparando una verificación previa por error

A veces, las personas cometen errores al tratar de construir solicitudes de Ajax, y otras veces provocan la necesidad de una verificación previa. Si la API está diseñada para permitir solicitudes de origen cruzado, pero no requiere nada que necesite una verificación previa, esto puede interrumpir el acceso.

Los errores comunes que desencadenan esto incluyen:

• tratando de poner Access-Control-Allow-Origin y otros encabezados de respuesta CORS en la solicitud. Estos no pertenecen a la solicitud, no hacen nada útil (¿cuál sería el punto de un sistema de permisos en el que podría concederse permiso?), Y deben aparecer solo en la respuesta.
• tratando de poner un Content-Type: application/json encabezado de Content-Type: application/json en una solicitud GET que no tiene cuerpo de solicitud para describir el contenido (generalmente cuando el autor confunde Content-Type y Accept ).

En cualquiera de estos casos, eliminar el encabezado de solicitud adicional a menudo será suficiente para evitar la necesidad de una verificación previa (que resolverá el problema al comunicarse con API que admiten solicitudes simples pero no solicitudes con verificación previa).

Respuestas opacas

Algunas veces necesita hacer una solicitud HTTP, pero no necesita leer la respuesta. por ejemplo, si publica un mensaje de registro en el servidor para su grabación.

Si está utilizando la API de fetch (en lugar de XMLHttpRequest ), puede configurarla para que no intente utilizar CORS.

Tenga en cuenta que esto no le permitirá hacer nada que CORS debe hacer. No podrá leer la respuesta. No podrá realizar una solicitud que requiera una verificación previa.

Le permitirá realizar una solicitud simple, no ver la respuesta y no llenar la Consola de desarrollador con mensajes de error.

La forma de hacerlo se explica en el mensaje de error de Chrome que aparece cuando realiza una solicitud utilizando fetch y no obtiene permiso para ver la respuesta con CORS:

El acceso a la búsqueda en '' https://example.com/ '' desde el origen '' https://example.net '' ha sido bloqueado por la política de CORS: No hay encabezado '' Access-Control-Allow-Origin '' en el recurso solicitado. Si una respuesta opaca satisface sus necesidades, configure el modo de solicitud en ''no-cors'' para recuperar el recurso con CORS deshabilitado.

Así:

fetch("http://example.com", { mode: "no-cors" });

Alternativas a CORS

JSONP

Bob también podría proporcionar los datos utilizando un truco como JSONP que es cómo la gente cruzó el Ajax antes de que apareciera CORS.

Funciona presentando los datos en forma de un programa JavaScript que inyecta los datos en la página de Mallory.

Requiere que Mallory confíe en Bob para no proporcionar código malicioso.

Tenga en cuenta el tema común: el sitio que proporciona los datos tiene que decirle al navegador que está bien que un sitio de terceros acceda a los datos que envía al navegador.

Dado que JSONP funciona agregando un elemento <script> para cargar los datos en forma de un programa JavaScript que llama a una función que ya está en la página, el intento de utilizar la técnica JSONP en una URL que devuelve JSON fallará, generalmente con un error CORB - porque JSON no es JavaScript.

Mueve los dos recursos a un solo origen

Si el documento HTML en el que se ejecuta JS y la URL que se solicita están en el mismo origen (que comparten el mismo esquema, nombre de host y puerto), entonces la Política del mismo origen otorga permiso de forma predeterminada. CORS no es necesario.

Un proxy

Mallory podría usar el código del lado del servidor para obtener los datos (que luego podría pasar de su servidor al navegador de Alice a través de HTTP como de costumbre).

O bien:

• agregar encabezados CORS
• convertir la respuesta a JSONP
• existe en el mismo origen que el documento HTML

Ese código del lado del servidor podría ser escrito y alojado por un tercero (como CORS Anywhere). Tenga en cuenta las implicaciones de privacidad de esto: el tercero puede controlar quién representa qué a través de sus servidores.

Bob no necesitaría otorgar ningún permiso para que eso suceda.

Esto estaría bien ya que es solo entre Mallory y Bob. Bob no tiene forma de pensar que Mallory es Alice y de proporcionar a Mallory datos que deben mantenerse confidenciales entre Alice y Bob.

En consecuencia, Mallory solo puede usar esta técnica para leer datos públicos .

Escribir algo que no sea una aplicación web

Como se señaló en la sección "Por qué la Política del mismo origen solo se aplica a JavaScript en una página web", puede evitar el SOP al no escribir JavaScript en una página web.

Eso no significa que no pueda seguir usando JavaScript y HTML, pero puede distribuirlo utilizando algún otro mecanismo, como Node-WebKit o PhoneGap.

Extensiones de navegador

Es posible que una extensión del navegador inyecte los encabezados CORS en la respuesta antes de que se aplique la Política del mismo origen.

Estos pueden ser útiles para el desarrollo, pero no son prácticos para un sitio de producción (no es razonable pedir a cada usuario de su sitio que instale una extensión de navegador que desactive una característica de seguridad de su navegador).

También tienden a funcionar solo con solicitudes simples (fallan cuando se manejan solicitudes OPTIONS de verificación previa).

Tener un entorno de desarrollo adecuado con un servidor de desarrollo local suele ser un mejor enfoque.

Otros riesgos de seguridad

Tenga en cuenta que SOP / CORS no mitiga XSS ataques de inyección XSS , CSRF o SQL que deben manejarse de forma independiente.

Resumen

• No hay nada que pueda hacer en su código del lado del cliente que permita el acceso de CORS al servidor de otra persona .
• Si controla el servidor, la solicitud se realiza para: Agregarle permisos CORS.
• Si eres amigable con la persona que lo controla: haz que le agreguen permisos CORS.
• Si se trata de un servicio público: lea la documentación de su API para ver qué dicen sobre cómo acceder a él con JavaScript del lado del cliente. Es posible que le indiquen que use URL específicas o que use JSONP (o puede que no lo admitan en absoluto).
• Si no se aplica nada de lo anterior: haga que el navegador se comunique con su servidor, y luego haga que su servidor obtenga los datos del otro servidor y los pase. (También hay servicios alojados de terceros que adjuntan encabezados CORS a recursos de acceso público que puede usar).

Answer 2

Como esto no se menciona en la respuesta aceptada.

• Este no es el caso para esta pregunta exacta, pero podría ayudar a otros que buscan ese problema
• Esto es algo que puede hacer en su código de cliente para evitar errores CORS en algunos casos .

Puede hacer uso de solicitudes simples .
Para realizar una ''Solicitud simple'', la solicitud debe cumplir varias condiciones. Por ejemplo, solo permite el método POST , GET y HEAD , así como solo permite algunos encabezados (puede encontrar todas las condiciones aquí ).

Si su código de cliente no establece explícitamente los encabezados afectados (por ejemplo, "Aceptar") con un valor fijo en la solicitud, puede ocurrir que algunos clientes establezcan estos encabezados automáticamente con algunos valores "no estándar", lo que hace que el servidor no los acepte como Solicitud simple: que le dará un error CORS.

Answer 3

Debe habilitar CORS para que funcione.

Answer 4

El servidor de destino debe permitir la solicitud de origen cruzado. Para permitirlo a través de express, simplemente maneje la solicitud de opciones http:

app.options(''/url...'', function(req, res, next){
   res.header(''Access-Control-Allow-Origin'', "*");
   res.header(''Access-Control-Allow-Methods'', ''POST'');
   res.header("Access-Control-Allow-Headers", "accept, content-type");
   res.header("Access-Control-Max-Age", "1728000");
   return res.sendStatus(200);
});

Answer 5

Este problema CORS no se elaboró ​​más (por otras causas).

Tengo este problema actualmente por diferentes razones. Mi front end también devuelve el error de encabezado ''Access-Control-Allow-Origin''.

Solo que señalé la URL incorrecta para que este encabezado no se refleje correctamente (en el que seguí suponiendo que sí). localhost (front end) -> llamada a http no seguro (se supone que es https), asegúrese de que el punto final de la API desde el front end esté apuntando al protocolo correcto.

Answer 6

Esto está sucediendo debido al error CORS. CORS significa Cross Origin Resource Sharing. En palabras simples, este error ocurre cuando intentamos acceder a un dominio / recurso desde otro dominio.

Lea más sobre esto aquí: error de CORS con jquery

Para solucionar esto, si tiene acceso al otro dominio, tendrá que permitir Access-Control-Allow-Origin en el servidor. Esto se puede agregar en los encabezados. Puede habilitar esto para todas las solicitudes / dominios o un dominio específico.

Cómo hacer que funcione una solicitud posterior de intercambio de recursos de origen cruzado (CORS)

Estos enlaces pueden ayudar