session - Cómo mostrar mensajes al usuario después de una redirección POST+HTTP

redirect user-interface

Question

Estoy usando el patrón PRG para evitar el envío de formularios múltiples. Tiene, sin embargo, un serio inconveniente: no se puede simplemente hacer echo del mensaje de confirmación al usuario (obviamente, el usuario no verá la página, se le redirigirá a otra).

¿Cuáles son las soluciones a este problema? Conozco a dos de ellos, pero ninguno de ellos parece perfecto.

• Use una URL de redireccionamiento personalizada, como: http://example.com/?msg=data-saved . Es sin estado, así que creo que es bastante confiable. Pero crea problemas cuando el usuario copia el enlace, lo marca, etc.
• Almacene una variable / cookie de sesión y verifíquela en cada carga de página. Si está configurado, desactívelo y muestre el mensaje. Parece correcto, pero no estoy seguro de este: depende en gran medida de las cookies, es un poco más complicado.

¿O tal vez hay otras formas que no conozco? Alguna combinación de sesiones y parámetros de URL? No sé.

¿Cuál es la mejor manera en tu opinión? ¿Cuál tiene menos inconvenientes? ¿Cuáles son los pros y los contras?

Answer 1

Depende de la plataforma en la que se ejecute.

Ruby on Rails llama a este flash [: notice] = "Tu acción se realizó", ASP.NET MVC llama a este TempData ["notice"] = "Tu acción se realizó" ...

Básicamente solo almacenan datos en HttpSession para un solo viaje de ida y vuelta. De esta forma puede recuperar datos en otra solicitud web.

Answer 2

Hay varias otras preguntas de desbordamiento de pila que tocan sobre esto, aunque no creo que ninguna resuma el problema tan claramente. Aquí hay algunos:

• ¿Cómo implemento el patrón Publicar / Redirigir / Obtener en asp.net WebForms?
• Response.Redirect con POST en lugar de Get?
• Tanto HTTP GET con cuerpo de solicitud como ¿Puede un HTTP GET contener contenido legalmente? abordar el problema, y ​​vale la pena leer las discusiones.
• ¿Cómo mantengo los errores de ModelState cuando uso RedirectToAction?

La mayoría de las soluciones convenientes están basadas en sesiones o tienen inconvenientes más serios (como incrustar el mensaje en la cadena de consulta).

Si no puede garantizar que tendrá sesiones, otro método (bastante costoso) es redireccionar a diferentes vistas dependiendo del resultado del envío del formulario. Por ejemplo, puede redirigir a EditWidgetView , EditWidgetSaveSuccessfulView o EditWidgetSaveErrorView (o tal vez simplemente no redirige a errores). En algunos idiomas y marcos, esto no es práctico hasta el punto de hacerle renunciar a mostrar mensajes de confirmación / error, pero en otros puede valer la pena.

Answer 3

Llegando muy tarde a esta discusión ...

Podría usar una combinación de las dos opciones propuestas.

Después de la solicitud POST, el cliente es redireccionado (303) a una URL que indica que podría haber un mensaje de respuesta para esta solicitud:

Client: GET http://example.com/foo.cgi
Server: 200 Ok
Client: POST http://example.com/bar.cgi
Server: 303 http://example.com/foo.cgi?msg=true

Si el argumento msg es true el mensaje se buscará en la sesión y (si se encuentra) incluido en la respuesta al cliente.
Si el argumento msg es ! true ! true (o no presente), el paso de búsqueda se omite.

Con esta solución, evita que se muestre el mensaje real en la URL, la URL solo indica que podría haber un mensaje. Además, el mensaje solo se muestra cuando es necesario (= cuando se encuentra en la sesión).

Otra ventaja es que esta solución también permite que se incluyan controles de efectivo adecuados con las respuestas HTTP.

Answer 4

Prácticamente todos los sitios web que permiten a los usuarios iniciar sesión lo hacen confiando en una cookie. No es una solución perfecta, pero es lo mejor que tenemos.

Además, el manejo de la sesión es una de esas cosas que un marco de desarrollo web normalmente se ocupa de ti.

Answer 5

Si no quiere confiar en las sesiones por el motivo que sea, podría utilizar una url Get get / custom y luego, si esa variable está presente, verifique la referencia. Si el referido es correcto, entonces muestre el mensaje. Sí, esto aumenta la dependencia de los envíos que se envían para mostrar el mensaje de confirmación, pero de lo contrario depende de las sesiones (que si bien son confiables, tampoco son 100% perfectas para todas las soluciones).

Y, sinceramente, algunos sitios grandes que normalmente son bastante buenos acerca de este tipo de cosas simplemente incluyen un "actiondone = true" en la url. (He notado que Facebook lo hace en algunos lugares).

Answer 6

Yo uso el método de la variable de sesión. Realmente no me gusta incrustar mensajes de error para mostrar en la URL, especialmente con los problemas de guardar / compartir URL que notas, y me gusta que si el usuario vuelve a cargar la página de destino será una instancia limpia.