origin - HTTP 302 La redirección a una solicitud CORS es eliminada por los navegadores
response to preflight request doesn''t pass access control check (2)
Estoy cargando una página HTML con algún javascript del sitio A.
Javascript envía una solicitud HTTP GET al sitio B. En este punto:
- El navegador envía la solicitud de OPCIONES al sitio B
- El sitio B responde a la solicitud de OPCIONES
- El navegador luego envía la solicitud HTTP GET original al sitio B
- El sitio B responde con HTTP 302 con la ubicación establecida en el sitio C.
En este punto, el navegador deja de procesar la solicitud. Esperaba que enviara la solicitud de OPCIONES HTTP al sitio C tal como lo hizo cuando envió la solicitud al sitio B. Pero no fue así. Observé el mismo comportamiento en Firefox y Chrome.
Me gustaría entender por qué los navegadores se comportan de esta manera. Entiendo que debería haber algunas verificaciones o redirecciones máximas para evitar bucles, pero no se limitan a 2 solicitudes de redirección.
También por qué la información del encabezado NO se envía al código Javascript para que la aplicación pueda hacer algo al respecto. El navegador simplemente lo elimina, aunque le molesta al mostrar la respuesta HTTP 302 del sitio C con la URL de ubicación en la consola del navegador.
XMLHttpRequest no puede cargar https: // siteB / ... La solicitud se redirigió a '' https: // siteC / ...'', que no está permitida para las solicitudes de origen cruzado que requieren verificación previa.
Cualquier apreciación del diseño es sinceramente apreciada.
Saludos
Bueno, tuve el mismo problema que tú, y desafortunadamente, este comportamiento es normal, según las especificaciones del W3C.
Esta especificación describe el comportamiento del navegador con respecto a CORS como un estado de la máquina, y si salta al paso 3 (haciendo la solicitud real), indica claramente:
Esta es la solicitud real. Aplique los pasos para realizar una solicitud y observe las reglas de solicitud a continuación al realizar la solicitud.
Si la respuesta tiene un código de estado HTTP de 301, 302, 303, 307 o 308, aplique los pasos de error de red y caché.
Por lo tanto, si entiendo correctamente, no podemos esperar que el navegador siga automáticamente la redirección en caso de un CORS (supuestamente, como la OPCIÓN ha otorgado acceso a otro recurso. Pero, ¿por qué no enviar automáticamente otra solicitud de OPCIÓN a este recurso?) .
Lo que es peor, ya que los HEADERS de la respuesta están ocultos por el navegador después de que la redirección automática fallara por la razón anterior, no tenemos acceso al encabezado de Ubicación para manejar la llamada subsiguiente al recurso correcto. Por lo tanto, no hay forma de obtener el recurso real en este caso.
Considero que esto es un error, pero no pude encontrar ninguna buena publicación sobre el tema en la web.
Una solución, si es posible para usted, es no hacer una solicitud CORS, sino usar una solicitud simple (de acuerdo con la especificación nuevamente, como un GET simple sin encabezados personalizados), que no hará que se envíen solicitudes de verificación previa: en este caso, la redirección funciona normalmente (seguida automáticamente por el navegador).
De lo contrario, podría ver si puede ajustar su servidor para que no responda 302 en caso de una solicitud tipo CORS, sino que responda con un código HTTP personalizado que pueda identificar en su cliente para incluir la ubicación de redireccionamiento en el contenido del Respuesta para que tu cliente la siga manualmente.
Si alguien tiene información válida sobre por qué es este comportamiento, por favor, dé su opinión :-)
Espero eso ayude.
No estoy seguro de que mi respuesta funcione o no para su caso.
Mi solicitud de cliente es redirigida por cosign; por lo tanto, tengo un cosign url en Access-Control-Allow-Origin. Y funciona para mi. Además, agregue xhrFields withCredentials en el cliente AJAX.
$.ajax( {url:url, success:function(result){ alert(result.toString()); }
,xhrFields: {withCredentials: true}
Y el servidor .NET tiene el SupportsCredentials = true
[EnableCors(origins: "https://cosign_URL", headers: "*"
, methods: "get,post", SupportsCredentials = true)]