Cómo mostrar mensajes al usuario después de un POST + HTTP redirigir

Question

Estoy usando el PRG pattern para evitar el envío de formularios múltiples. Sin embargo, tiene un serio inconveniente: no se puede simplemente echo el mensaje de confirmación para el 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.
• Almacena una variable de sesión/cookie, 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 su opinión? ¿Cuál tiene menos inconvenientes? ¿Cuáles son los pros y los contras?

Answer 1

Casi 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.

También el manejo de sesiones es una de esas cosas que un marco de desarrollo web normalmente se ocupa de usted.

Answer 2

Utilizo 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.

Answer 3

Depende de la plataforma en la que se ejecute.

Ruby on Rails llama este flash [: aviso] = "Se llevó a cabo su acción", ASP.NET MVC llama a esto TempData [ "aviso"] = "Se llevó a cabo su acción" ...

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

Answer 4

Hay varias otras preguntas de desbordamiento de pila que tocan sobre esto, aunque no creo que se resuma el problema tan claramente. Éstos son algunos de ellos:

• How do I implement the Post/Redirect/Get pattern in asp.net WebForms?
• Response.Redirect with POST instead of Get?
• Tanto HTTP GET with request body y Can an HTTP GET legally contain content? tratan esta cuestión, y las discusiones son vale la pena leer.
• How do I maintain ModelState errors when using RedirectToAction?

La mayoría de las soluciones convenientes están basadas en sesiones o tienen inconvenientes más graves (como la incorporación del mensaje en la cadena de consulta).

Si no puede garantizar que tendrá sesiones, otro método (bastante costoso) es redirigir 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 5

Si no desea confiar en las sesiones por cualquier razón, puede usar una URL de Obtener variable/personalizada y luego, si esa variable está presente, verifique la referencia. Si el referido es correcto, entonces muestre el mensaje. Sí, esto se basa en los envíos enviados para mostrar el mensaje de confirmación, pero de lo contrario depende de las sesiones (que aunque confiables, tampoco son 100% perfectos para todas las soluciones).

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

Answer 6

viene muy tarde para esta discusión ..

se puede utilizar una combinación de las dos opciones propuestas.

Después de la solicitud POST se redirige al cliente (303) a una dirección 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 será buscado en la sesión y (si se encuentra) incluida en la respuesta al cliente.
Si el argumento msg es ! true (o no está presente), el paso de búsqueda se omite.

Con esta solución, evita que el mensaje real se muestre 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.