Prevenir la devolución de datos cuando el usuario hace clic el botón atrás del navegador

Question

Tengo una página web que envía correo electrónico a varios usuarios (lista de distribución en línea). Después de hacer clic en el botón de enviar y el correo electrónico se envía, una página de estado se muestra en el listado de cómo se enviaron muchos mensajes de correo electrónico, errores, y otra información. Si el usuario hace clic en el botón de retroceso, el correo electrónico se reenvía. ¿Cómo puedo evitar esto?

NOTA: El navegador solicitan al usuario la información "reenvío" a la página de "volver a ejecutar" o antes de que realmente enviar el correo electrónico, pero eso no impide que mis usuarios hacer clic en él y luego se pregunta por qué dos copias del correo electrónico fueron enviados a cabo.

Medio ambiente:

• Servidor: C #, ASP.NET 2.0, IIS6
• Cliente: cualquier navegador (no quiero una solución IE-específico como SmartNavigation)

Answer 1

En su código, justo después del punto en el que se envían correos electrónicos, hacer una redirección 302 a una página de confirmación:

protected void btnSend_Click(object sender, EventArgs e)
{
    SendManyEmails();
    Response.Redirect("confirmation.aspx");
}

Con este tipo de código, el envío a la página original no va a terminar en el historial del navegador.

Este patrón común es conocido como el Mensaje / Redirigir / Obtener patrón .

Información de bonificación por mantener el estado cuando se hace de correos / Redirigir / Obtener

El principal inconveniente de este patrón es que todo el estado de la manipulación de la solicitud POST se pierde cuando redirigir al usuario - por lo tanto, comenzando un nuevo contexto de la petición. En ASP.NET esto incluye miembros dentro de la Page y todos los objetos Control, así como todo lo almacenado en el ViewState.

Si se genera una especie de "objeto de estado" - tal vez un registro de los mensajes de correo enviados - durante la manipulación de la solicitud POST, necesitará alguna forma de salvar este objeto para la siguiente petición GET. Algunos marcos web tiene una funcionalidad específica para esto: RoR tiene flash, ASP.NET MVC tiene TempData. formularios ASP.NET no tiene tal concepto incorporado, por lo que tendrá que pensar en algo a sí mismo.

Guardar el objeto a la Session en el POST, la lectura y eliminarlo en el siguiente GET sería una manera de resolver esto. Se puede construir una abstracción en torno a este si lo usa en varios lugares, o se puede buscar en la web para las implementaciones existentes de flash / TempData de formularios ASP.NET.