¿Es posible atrapar errores CORS?

Question

Esta pregunta está relacionada con el intercambio de recursos de origen cruzado (CORS, http://www.w3.org / TR / cors / ).

Si hay un error al realizar una solicitud CORS, Chrome (y AFAIK también otros navegadores) registra un error en la consola de errores.Un mensaje de ejemplo puede verse así:

XMLHttpRequest no puede cargar http://domain2.example.Origin http://domain1.example no está permitido por Access-Control-Allow-Origin.

Me pregunto si hay alguna forma de obtener este mensaje de error mediante programación.Intenté envolver mi llamada xhr.send() en try / catch, también intenté agregar un controlador de eventos onerror().Ninguno de los cuales recibe el mensaje de error.

Answer 1

Ver:

• http:// www .w3.org / TR / cors / # handling-a-response-to-a-cross-origin-request

... así como notas en XHR Nivel 2 sobre CORS:

• http://www.w3.org/TR/XMLHttpRequest2/

La información se filtra intencionalmente.

Editar muchos meses después: un comentario de seguimiento aquí preguntaba "por qué"; al ancla en el primer enlace le faltaban algunos caracteres, lo que dificultaba ver a qué parte del documento me refería.

Es una cuestión de seguridad: un intento de evitar exponer información en encabezados HTTP que pueden ser confidenciales. El enlace del W3C sobre CORS dice:

Los agentes de usuario deben filtrar todos los encabezados de respuesta que no sean un encabezado de respuesta simple o cuyo nombre de campo sea una coincidencia ASCII que no distinga entre mayúsculas y minúsculas para uno de los valores de los encabezados Access-Control-Expose-Headers (si any), antes de exponer los encabezados de respuesta a las API definidas en las especificaciones de la API de CORS.

Ese pasaje incluye enlaces para "encabezado de respuesta simple", que enumera Cache-Control, Content-Language, Content-Type, Expires, Last-Modified y Pragma. Entonces esos pasan. La parte "Encabezados de Access-Control-Expose-Headers" permite al servidor remoto exponer otros encabezados también incluyéndolos allí. Consulte la documentación del W3C para obtener más información.

Recuerde que tiene un origen, digamos que es la página web que ha cargado en su navegador, que ejecuta un poco de JavaScript, y el script realiza una solicitud a otro origen, lo que normalmente no está permitido porque el malware puede hacerlo. cosas desagradables de esa manera. Entonces, el navegador, que ejecuta el script y realiza las solicitudes HTTP en su nombre, actúa como guardián.

El navegador mira la respuesta de ese servidor de "otro origen" y, si no parece estar "participando" en CORS (faltan los encabezados requeridos o están mal formados), entonces estamos en una posición de no confiar. No podemos estar seguros de que el script que se ejecuta localmente esté actuando de buena fe, ya que parece estar intentando contactar con servidores que no esperan ser contactados de esta forma. El navegador ciertamente no debería "filtrar" ninguna información sensible de ese servidor remoto simplemente pasando su respuesta completa al script sin filtrar - eso sería básicamente permitir una especie de solicitud de origen cruzado. Surgiría una vulnerabilidad de divulgación de información.

Esto puede dificultar la depuración, pero es una compensación entre seguridad y usabilidad donde, dado que el "usuario" es un desarrollador en este contexto, la seguridad tiene una prioridad significativa.