Cómo evitar volver a enviar un formulario. Reenvío de datos del formulario al actualizar la página. Evitar el reenvío de formularios mediante una redirección de cliente

En un momento me desconcertó la pregunta: cómo proteger las páginas del sitio para que no vuelvan a enviar los datos del formulario durante la actualización de la página (si antes de eso hubo un envío, por supuesto).
Todo webmaster y desarrollador probablemente sepa que si en el sitio hizo clic en el botón "enviar" al completar un formulario, luego de enviarlo, si intenta actualizar la página, el navegador mostrará un mensaje confirmando el reenvío.
En algunos momentos, esto es inaceptable. Por ejemplo, en el caso de la forma elemental realimentación... Cuando el usuario llenó el formulario y envió un mensaje, y luego, por alguna razón que él conocía, actualizó la página, la carta desapareció nuevamente. Este puede, por supuesto, no ser un caso tan fatal, solo como un ejemplo. Todo es mucho más doloroso, por ejemplo, al enviar un pedido en una tienda online.
Así que me planteé la cuestión de encontrar una solución a este problema y me di cuenta de que solo hay una solución: usar la redirección después de enviar el formulario de encabezado ("ubicación: dirección"). Aquellos. todo es simple: después del envío, llamamos a un redireccionamiento (incluso puedes ir a la misma página) ¡y eso es todo! La actualización de la página será limpia, sin POST ni GET llenos.

Todo está bien, pero personalmente tuve algunos problemas con esto. Son los siguientes. Anteriormente, sin usar redireccionamientos, el mecanismo para enviar datos en mis sitios funcionaba de la siguiente manera:
El usuario completa el formulario, hace clic en "enviar", el script acepta los datos enviados, verifica su exactitud (validez, integridad de los datos requeridos, etc.) y da una respuesta: la operación fue exitosa o se produjo un error y una lista de errores (por ejemplo: error - el campo "nombre" no está lleno. Y en la página de envío, a su vez, se muestra el mensaje correspondiente: el envío es exitoso o no exitoso.
Si el envío no es exitoso, el formulario permanece en la pantalla y sus campos se llenan con los datos que ingresó el usuario. Aquellos. los datos se toman de la variable $ _POST (si Método POST) y entrar en los campos correspondientes (es decir, vuelven de la publicación a sus campos para no volver a introducirlos). Después de todo, todos se enfurecen cuando llenó el formulario, y Dios no permita que haya indicado algo incorrectamente y cuando intente enviarle un mensaje se muestra que algo se completó incorrectamente, y el formulario se actualiza y vuelve a estar vacío. Y debe volver a completarlo debido a un campo llenado incorrectamente.
Entonces, como dije, en caso de llenado incorrecto, el formulario permanece lleno con datos tomados de $ _POST, y el usuario puede corregir los datos incorrectos y enviar el formulario nuevamente.
Todo estuvo bien y todo funcionó.
Pero luego hice un envío usando redirección y resultó que después de presionar el botón "enviar", en caso de llenado incorrecto, el formulario se actualizó y los campos llenos ya no podían permanecer en él, porque Anteriormente, se llenaban automáticamente desde la matriz $ _POST, pero ahora, después de que se produjo la redirección, $ _POST se borró como si no hubiera ningún envío.
Pero incluso en este caso, había una salida. Utilice sesiones. Aquellos. antes de llamar al encabezado, transfiera los datos de POST a las variables de sesión y solo entonces, después de la redirección, opere con ellas.
Como resultado, el código se volvió mucho más complejo. La depuración se ha vuelto más difícil porque en general, es difícil determinar qué sucede con las funciones en el momento en que se produce una redirección. Si cometió algún error en los códigos (que aparece exactamente en el momento del envío), entonces ni siquiera se mostrará, porque Se producirá una redirección y ni siquiera verá el mensaje de error.
En general, después de la introducción del encabezado en mis códigos, se me hizo más difícil trabajar con mis aplicaciones. La búsqueda de desarrollo / revisión / error se ha vuelto más difícil. Pero tampoco puedo rechazarlo.
Y me sigo preguntando: ¿hay otras soluciones más elegantes?

Proceso de envío Formularios HTML pueden pasar unos segundos antes de que el formulario se envíe correctamente y se muestre la página de respuesta. Los usuarios que no son lo suficientemente pacientes pueden hacer clic en el botón Enviar varias veces, lo que hace que se vuelva a enviar el formulario. Por lo general, esto no es un problema, pero en algunos casos puede evitar que esto suceda.
A continuación encontrará dos trucos sencillos para evitar la duplicación de mensajes, puede utilizar uno o una combinación de estos.

Evitar múltiples envíos con Javascript

Probablemente usar Javascript para evitar volver a enviar el formulario es lo más de una manera fácil... Cuando el usuario envía el formulario, puede deshabilitar el botón "Enviar" y cambiar su nombre a algo más comprensible "Enviando, por favor espere ..."

El primer paso es establecer un identificador único identificación, por ejemplo id = "myButton":

El segundo (y último) paso es configurar dos comandos Javascript en la etiqueta

... El primer comando deshabilitará el botón Enviar después de enviar el formulario y el segundo modificará el texto del botón para darle al usuario una idea de lo que está sucediendo. El siguiente código debe agregarse a la etiqueta :

La etiqueta del formulario se verá así:

onsubmit = "document.getElementById ('myButton']. disabled = true;

document.getElementById (‘myButton’). value = ’Enviando, espere ...’; "

Y después de presionar el botón, se convierte en tal

Eso es todo. Esta técnica debería funcionar en la mayoría de los navegadores (IE 5+, FireFox, Opera, Chrome).

Prevención de envíos múltiples mediante cookies

Si desea evitar volver a enviar formularios durante la sesión de su navegador (o más), es posible que desee considerar el uso de cookies. Por ejemplo, modifique la secuencia de comandos de edición de su formulario para pasar la cookie al navegador después de que se haya procesado el formulario, pero antes de que se envíen los encabezados HTML. Colocar este código después del comando mail () debería funcionar en la mayoría de los casos:

setcookie ("Formulario enviado", "1");

Luego, verifique la cookie antes de procesarla. Si ya se han creado, entonces el usuario ya ha enviado el formulario en una sesión activa del navegador. Agregue el siguiente código al comienzo del script para procesar el formulario.

{
morir ("¡Solo puede enviar el formulario una vez por sesión!");
}

Eso es todo.

Así es como se verá el script final usando cookies para bloquear reenvíos. Observe que parte del código se ha agregado en la parte superior del script y que el código para escribir la cookie está después de la función mail ().

/ * Evitar el reenvío * /

if (isset ($ _ COOKIE [‘FormSubmitted’])
{
show_error ("¡Solo puede enviar el formulario una vez por sesión!");
}

/ * Establecer destinatario de correo electrónico * /

$ myemail = " [correo electrónico protegido]»;

/ * Verificando los valores ingresados en el formulario usando la función check_input * /

$ yourname = check_input ($ _ POST [‘yourname’], "Por favor ingrese su nombre");
$ asunto = check_input ($ _ POST ['asunto'], "Asunto de la publicación");
$ correo electrónico = check_input ($ _ POST ['correo electrónico']);
$ sitio web = check_input ($ _ POST ['sitio web']);
$ likeit = check_input ($ _ POST ['likeit']);
$ how_find = check_input ($ _ POST ["cómo"]);
$ comentarios = check_input ($ _ POST ['comentarios'], "Sus comentarios");

/ * Si se ingresa una dirección de correo electrónico no válida, muestra un mensaje de error * /
si (! preg_match ("/ ( [correo electrónico protegido]+. +) / ", $ Correo electrónico))
{
show_error ("Ingresó un correo electrónico incorrecto");
}

/ * Si la URL es incorrecta, configure la variable $ website en vacío * /
if (! preg_match ("/^(https?://++.+)/i", $ sitio web))
{
$ sitio web = ";
}

/ * Preparar un mensaje de correo electrónico * /

$ mensaje = “¡Hola!
Se han enviado sus datos de contacto:
Nombre: $ yourname
Correo electrónico: $ correo electrónico
URL: $ sitio web
¿Te gusta la página? $ likeit
Cómo encontraste el sitio web? $ how_find

En un momento me desconcertó la pregunta: cómo proteger las páginas del sitio para que no vuelvan a enviar los datos del formulario durante la actualización de la página (si antes de eso hubo un envío, por supuesto).
Todo webmaster y desarrollador probablemente sepa que si en el sitio hizo clic en el botón "enviar" al completar un formulario, luego de enviarlo, si intenta actualizar la página, el navegador mostrará un mensaje confirmando el reenvío.
En algunos momentos, esto es inaceptable. Por ejemplo, en el caso de un formulario de retroalimentación elemental. Cuando el usuario llenó el formulario y envió un mensaje, y luego, por alguna razón que él conocía, actualizó la página, la carta desapareció nuevamente. Este puede, por supuesto, no ser un caso tan fatal, solo como un ejemplo. Todo es mucho más doloroso, por ejemplo, al enviar un pedido en una tienda online.
Así que me planteé la cuestión de encontrar una solución a este problema y me di cuenta de que solo hay una solución: usar la redirección después de enviar el formulario de encabezado ("ubicación: dirección"). Aquellos. todo es simple: después del envío, llamamos a un redireccionamiento (incluso puedes ir a la misma página) ¡y eso es todo! La actualización de la página será limpia, sin POST ni GET llenos.

Todo está bien, pero personalmente tuve algunos problemas con esto. Son los siguientes. Anteriormente, sin usar redireccionamientos, el mecanismo para enviar datos en mis sitios funcionaba de la siguiente manera:
El usuario completa el formulario, hace clic en "enviar", el script acepta los datos enviados, verifica su exactitud (validez, integridad de los datos requeridos, etc.) y da una respuesta: la operación fue exitosa o se produjo un error y una lista de errores (por ejemplo: error - el campo "nombre" no está lleno. Y en la página de envío, a su vez, se muestra el mensaje correspondiente: el envío es exitoso o no exitoso.
Si el envío no es exitoso, el formulario permanece en la pantalla y sus campos se llenan con los datos que ingresó el usuario. Aquellos. los datos se toman de la variable $ _POST (si es el método POST) y se colocan en los campos correspondientes (es decir, se devuelven desde la publicación a sus campos para no volver a ingresarlos). Después de todo, todos se enfurecen cuando llenó el formulario, y Dios no lo quiera, indicó algo incorrectamente y cuando intenta enviarle un mensaje se muestra que algo se completó incorrectamente, y el formulario se actualiza y vuelve a estar vacío. Y debe volver a completarlo debido a un campo llenado incorrectamente.
Entonces, como dije, en caso de llenado incorrecto, el formulario permanece lleno con datos tomados de $ _POST, y el usuario puede corregir los datos incorrectos y enviar el formulario nuevamente.
Todo estuvo bien y todo funcionó.
Pero luego hice un envío usando redirección y resultó que después de presionar el botón "enviar", en caso de llenado incorrecto, el formulario se actualizó y los campos llenos ya no podían permanecer en él, porque Anteriormente, se llenaban automáticamente desde la matriz $ _POST, pero ahora, después de que se produjo la redirección, $ _POST se borró como si no hubiera ningún envío.
Pero incluso en este caso, había una salida. Utilice sesiones. Aquellos. antes de llamar al encabezado, transfiera los datos de POST a las variables de sesión y solo entonces, después de la redirección, opere con ellas.
Como resultado, el código se volvió mucho más complejo. La depuración se ha vuelto más difícil porque en general, es difícil determinar qué sucede con las funciones en el momento en que se produce una redirección. Si cometió algún error en los códigos (que aparece exactamente en el momento del envío), entonces ni siquiera se mostrará, porque Se producirá una redirección y ni siquiera verá el mensaje de error.
En general, después de la introducción del encabezado en mis códigos, se me hizo más difícil trabajar con mis aplicaciones. La búsqueda de desarrollo / revisión / error se ha vuelto más difícil. Pero tampoco puedo rechazarlo.
Y me sigo preguntando: ¿hay otras soluciones más elegantes?