jquery - evitar - confirmar reenvio de formulario

Problema de redireccionamiento de AJAX, cómo obtener URL de redireccionamiento O cómo establecer propiedades para la solicitud de redireccionamiento

Question

Primero, estoy trabajando en Google Chrome, si eso ayuda. Aquí está el comportamiento:

Envío una solicitud xhr a través de jQuery a un sitio remoto (esta es una extensión de Chrome, y configuré todas las configuraciones entre sitios ...):

$.ajax({
    type: "POST",
    contentType : "text/xml",
    url: some_url,
    data: some_xml,
    username: user,
    password: pass,
    success: function(data,status,xhr){
        alert(data);
    },
    error: function(xhr, status, error){
        alert(xhr.status);
    }
});

La URL que se está configurando arroja un 302 (se espera), y Chrome sigue el redireccionamiento (también esperado).

La nueva URL devuelve una solicitud de credenciales, que no se extraen de la solicitud original, por lo que Chrome muestra un cuadro de diálogo de inicio de sesión. Si introduzco las credenciales originales, recibo una respuesta sobre una solicitud no válida enviada (es una solicitud HTTP válida - 200 - al servidor remoto simplemente no le gusta uno de los encabezados).

Al ver la ventana del desarrollador en Chrome, se envían dos solicitudes. El primero es para la URL original con todas las configuraciones establecidas en la solicitud AJAX. El segundo es para la URL de redireccionamiento, con un método de "GET", nada del campo "POST" y sin credenciales.

No sé qué puedo hacer. O bien necesito:

1. Obtenga la URL de redireccionamiento para poder enviar una segunda solicitud ( xhr.getResponseHeader("Location") NO funciona),

2. Haga que la nueva solicitud de redireccionamiento preserve la configuración de la solicitud original, o

3. Obtenga la URL final de la que proviene el error para poder enviar otra solicitud.

Idealmente, no quiero que el usuario tenga que ingresar sus credenciales por segunda vez en este cuadro de diálogo, pero tomaré lo que pueda obtener si puedo obtener la URL final.

Answer 1

¿no puedes usar windows.location = "newURL"? eso solía funcionar para mí para redirigir

Answer 2

Como Rajiv M. ha indicado anteriormente, no puede capturar 302 redireccionamientos utilizando un objeto XHL o una solicitud AJAX.

Su mejor opción es configurar un proxy de algún tipo en PHP / ASP o en cualquier lenguaje de scripting del lado del servidor. La secuencia de comandos PHP simplemente seguirá 302 redirecciones hasta que llegue a un destino final. Luego, puede enviar la URL final a su página de JavaScript. Ahora las futuras solicitudes de AJAX se pueden enviar directamente a la URL final conocida.

O...

Su script PHP solo servirá como un proxy. Todas las solicitudes serán enviadas a este script PHP.

O...

Simplemente codifique la URL final en su aplicación de JavaScript, si es posible (aunque supongo que no es posible en su caso).

Lo siento, odio las respuestas de "no puedes hacer esto" también, pero hay algunas limitaciones de JavaScript que todavía no se han solucionado.

Answer 3

Desafortunadamente, no hay forma de evitar que xhr siga automáticamente los redireccionamientos o establezca las credenciales para el destino de redirección (de todos modos sería inseguro, ya que eso permitiría al primer sitio redirigir las credenciales a cualquier sitio, no solo el que desea obtener ellos).

Answer 4

En caso de que controle el servidor, puede incrustar los datos que se pierden en la dirección de redirección. Entonces xhr hace un POST, y luego hace un GET con algunos de los datos POSTed que están siendo codificados de vuelta (por el servidor) como GET params. No hay otras soluciones que surjan para mí ...

Answer 5

En función de su pregunta, no estoy del todo seguro de si se está refiriendo a la Autenticación HTTP o a un esquema de autenticación basado en formularios, y por lo tanto abordaré ambos.

Obtenga la URL de redireccionamiento para poder enviar una segunda solicitud (xhr.getResponseHeader ("Ubicación") NO funciona),

Con la forma en que se construye XHR en general (y en Chrome específicamente): XHR no es muy flexible y proporciona una API relativamente de alto nivel, con el mismo comportamiento que el navegador en todas las demás solicitudes (URL de barra de direcciones, URL de fuente de imagen, URL de scripts incrustados), es decir, los redireccionamientos se manejan de forma transparente. No se generarán eventos en el JavaScript que le avise de este redireccionamiento o en los códigos de estado intermedios 302/301, solo recibirá el código y los datos del estado final. Por lo tanto, es imposible recuperar el encabezado "Ubicación" de la respuesta, ya que la respuesta final no contendrá el encabezado "Ubicación".

Haga que la nueva solicitud de redireccionamiento preserve la configuración de la solicitud original.

XHR no proporciona esto como una opción y sería un comportamiento predeterminado incorrecto. Ejemplo de por qué esto debería y no debería ocurrir por defecto:

Acme corp proporciona un servicio de enlaces cortos de URL para sus empleados. Hago clic en un enlace corto que recibo de un compañero de trabajo y el servicio de enlaces cortos de Acme me pide una autenticación HTTP. La redirección se produce después de esta autenticación. No hay ninguna razón para que el sitio al que se redirige requiera mis credenciales, y por lo tanto, sería un comportamiento incorrecto para el navegador pasar esta información (y de hecho, un problema de seguridad). Del mismo modo, los datos POST no se deben reenviar, ya que solo pueden ser destinados al consumo por la URL pre-directa.

Obtenga la URL final de la que proviene el error para poder enviar otra solicitud.

Desafortunadamente, por razones de seguridad y definición de estándares, el objeto XHR estándar (incluido el que usa Chrome para solicitudes entre sitios en extensiones) no proporciona ninguna forma de acceder a la URL final que tiene un error. Solo puede acceder al estado HTTP final y a todos los datos devueltos por la URL final.

-

Teniendo esto en cuenta, tiene algunas opciones según cuánto control tenga sobre la situación:

1) Si tiene control sobre el servidor de redirección, considere incluir información. en sus solicitudes AJAX indicando un cliente AJAX, y haga que el servidor en su lugar devuelva datos (es decir, un objeto json) que indique que se debe realizar una redirección.

O bien, si la intención es transmitir siempre los datos de autenticación, considere implementar algún mecanismo para pasar la sesión o incluir información de autenticación. en la URL a la que se redirige para que la URL de destino pueda consumir esta información.

2) Si tiene control sobre el destino de la redirección, considere incluir la URL del destino al generar una página de falla de autenticación. El objeto XHR tendrá acceso a esta información de respuesta y puede analizarla para proceder con una nueva solicitud.

3) Si no tiene control sobre el sitio de redirección o el sitio de destino, considere hospedar un servidor de proxy para manejar las solicitudes y atrapar específicamente el 302.

http://myserver/?url=http://redirectsite.com&user=...&pass=...

4) Si ninguna de las opciones anteriores son opciones, la opción menos deseable pero viable es crear una extensión NPAPI para Chrome que ejecute código nativo. Esto le dará control total sobre las solicitudes y le permitirá hacer casi cualquier cosa. Sin embargo, tenga en cuenta que esto es a expensas de un desarrollo más complejo, posibles problemas de seguridad y menos atractivo para el usuario.

Answer 6

Podría intentar el tipo de solución que se describe aquí: Cómo administrar una solicitud de redireccionamiento después de una llamada jQuery Ajax

Eso significa que, de hecho, reemplaza el protocolo HTTP, también necesitará controlar el servidor. Todas las respuestas ajax estarán en el código 200 (o al menos las 3xx, no en la 401/403) con un objeto json. y en este objeto JSON puede proporcionar algún código de error especial (¿por qué no reutilizar?

Luego extiende la función jQuery.ajax para capturar estos códigos especiales en su respuesta json y hacer las nuevas solicitudes necesarias. De hecho, la llamada a la redirección de jQuery automática la realiza usted y no jQuery.

al principio esto parece feo, pero cuando se trata de problemas como el sugerido en el enlace (fin de sesión, redirigir en la página de inicio de sesión) parece que tener un manejo completo del protocolo en las comunicaciones ajax json entre el cliente y el servidor no es un mala idea.