Utilice esta guía para resolver problemas comunes en la ventana de la consola del navegador relacionados con el Access-Control-Allow-Origin mensaje de error. A continuación se muestran ejemplos de mensajes de error.
- No se pudo cargar… No hay encabezado “Access-Control-Allow-Origin”
- Solicitud de origen cruzado (Cross-Origin) bloqueada: La política de mismo origen no permite leer el recurso remoto… Razón: Falta el encabezado CORS “Access-Control-Allow-Origin”
- No se pudo cargar… La respuesta a la solicitud de verificación previa no pasa la verificación de control de acceso: No hay encabezado “Access-Control-Allow-Origin” en el recurso solicitado. Por lo tanto, Origin… no tiene acceso
Este artículo contiene los siguientes temas.
Causas del error
Una aplicación web basada en navegador (posiblemente una aplicación del framework de aplicaciones) está intentando hacer una llamada origen cruzado (cross-origin) para obtener un recurso compartido de un servicio web externo. Esto se conoce como una solicitud CORS (Cross-Origin-Resource-Sharing).
Existe un estándar CORS basado en navegador que gestiona dichas llamadas de origen cruzado. Cuando no se cumplen ciertas condiciones, pueden ocurrir errores.
Esto no es un error necesariamente, porque quizás se relacione con un caso de uso que no está permitido intencionalmente por la aplicación web del usuario y el servicio externo remoto.
Cuando un origen (www.origin1.com) llama a otro origen (www.origin2.com), eso se conoce como solicitud de origen cruzado. Deben existir ciertas condiciones para que esta solicitud funcione. El servicio externo al que se llama (www.origin2.com) debe devolver el encabezado HTTP Access-Control-Allow-Origin en su respuesta.
Si el servicio externo no devuelve este encabezado, la adherencia del navegador a la especificación CORS detiene la solicitud y se devuelve uno de los errores anteriores.
Preguntas para la resolución de problemas
- ¿Cuál es la URL de punto de partida de la llamada (o el origen)?
Esto a veces se encuentra en el propio mensaje de error. - ¿Cómo se llama la URL del servicio externo?
Esto a veces aparece en el mensaje de error de la consola. - ¿Qué se recupera y por qué? ¿Es un archivo PNG? ¿Un script, CSS o un archivo de fuentes? ¿Qué se está recuperando exactamente y para qué se está usando?
Esto puede proporcionar información sobre el caso de uso y por qué el recurso de esta ubicación remota es importante. - ¿Este recurso externo requiere obtener autenticación?
Si se requiere un redireccionamiento, es posible que no se devuelva el encabezado de respuestaAccess-Control-Allow-Originy la llamada fallará. Copie la URL del recurso directamente en una nueva pestaña de incógnito del navegador. Esta puede ser una buena prueba para determinar si se puede acceder a ello bajo circunstancias generales, pero no es una garantía de que funcionará en el código de la aplicación web. - ¿Puede ver la llamada del método HTTP OPTIONS en la pestaña Red del navegador?
Si existen encabezados de solicitud personalizados, autenticación u otras condiciones en la solicitud de origen cruzado, el navegador realiza una llamada HTTP adicional. Esto también se conoce como llamada previa (preflight call). El código de la aplicación web no la hace explícitamente. El navegador en segundo plano la crea y la convierte en parte del estándar de especificación CORS.
Cuando se hace esta llamada de OPTIONS, deben existir ciertos valores en la respuesta de esta llamada para que se haga correctamente y para que suceda la llamada HTTP real para el recurso. Si la llamada de OPTIONS falla, el recurso no se recupera y debería aparecer un error CORS en la consola del navegador. Anote si ve una llamada de OPTIONS. Anote también si ve una llamada de redireccionamiento (estado 302) justo antes de la llamada de OPTIONS. Si se está produciendo un redireccionamiento en una llamada de OPTIONS, lo más probable es que la llamada de OPTIONS falle. Esto significa que la llamada para obtener el recurso también fallará y se desencadenará un error CORS. - ¿Para qué sirve obtener recursos externos?
Averigüe por qué se está recuperando este recurso externo en primer lugar. Esto puede ser importante para encontrar soluciones temporales o cambios necesarios. - Genere un archivo HAR.
Obtener una sinopsis de la llamada que ha fallado y lo que ha sucedido inmediatamente antes y después puede ayudar a corregir el problema y evitar que el usuario lo repita. Se pueden examinar los encabezados de las solicitudes y respuestas, además de identificar las llamadas y los redireccionamientos de OPTIONS.
Posibles próximos pasos
- ¿A quién pertenece el servidor externo? Quizás se pueda modificar el servidor para que se adhiera al estándar de la especificación CORS para devolver el encabezado
Access-Control-Allow-Origin. Sin embargo, tenga en cuenta que incluso si el servidor es algo que se controla internamente, esto no es necesariamente algo que lo solucione todo. Puede haber buenas razones por las que un servicio externo en particular no desea compartir un recurso. Si el servidor externo no es algo que se controla internamente, entonces quizás sea mejor trabajar con ese proveedor o buscar otra solución, suponiendo que el caso de uso se considere válido. - ¿La aplicación está escrita usando el Zendesk App Framework? Hay un servidor proxy de back-end disponible a través de la llamada
client.request(). Use este proxy configurandocors:falseen la configuración de client.request. Tenga en cuenta que “false” es también el valor predeterminado de la configuración. Como el servicio de proxy es un servicio "back-end", no es necesario que cumpla la especificación CORS basada en navegador, de modo que la llamada de origen cruzado posiblemente tenga éxito si se usa el proxy.
Esto tampoco puede ser siempre la solución. El servicio proxy no admite la recuperación de archivos binarios ni información binaria de servicios externos. Puede que haya otras razones específicas a la aplicación por las que esto no sea una solución. - ¿Se puede incrustar el recurso directamente en la aplicación web? En lugar de recurrir a un origen cruzado para obtener un recurso, considere la posibilidad de incluirlo en la aplicación web. Esto evita por completo la llamada de origen cruzado (porque ahora es un recurso local) y los problemas con CORS pueden desaparecer. Sin embargo, esto no siempre es una solución. A veces, las URL de recursos externos no se conocen de antemano, o el recurso es demasiado grande para que se ajuste como un recurso local, o el recurso cambia muy a menudo para descargarlo como un recurso estático local.
- ¿Cuál es la versión del navegador? A pesar de que la especificación CORS sea un estándar, los mensajes de error devueltos por los navegadores pueden ser diferentes. Chrome devuelve mensajes de consola distintos a los de Firefox.
- A veces no hay solución. A veces, una solicitud de recursos de un servicio externo no está pensada para ser compartida en el contexto de una aplicación web de navegador. El dueño del recurso decide si comparte el recurso o no. No depende de la aplicación web. Esto podría depender del diseño.
Si desea más información, consulte los siguientes artículos:
- Artículo de Wikipedia: Intercambio de recursos de origen cruzado
- Artículo de Web.Dev (en inglés): Cross-Origin Resource Sharing (CORS)
- Artículo de Mozilla: Cross-Origin Resource Sharing (CORS)
- Artículo de Mozilla:
OPTIONS - Artículo de Fetch (en inglés): Fetch
- Artículo de Fetch (en inglés): CORS protocol
0 comentarios