significa - post y pre

Prevención del doble HTTP POST (11)

He hecho una pequeña aplicación para suscribirse a un evento. El usuario ingresa sus datos y hace clic en "iniciar sesión".

Ahora, a veces las personas son dobles en la base de datos, exactamente los mismos datos que se insertaron 2 veces muy rápidamente después de cada uno. Esto solo puede significar que alguien presionó el botón dos veces, lo que provocó que dos publicaciones tuvieran lugar.

Este es un problema web común, ya que las aplicaciones de tarjetas de crédito y las aplicaciones de foros a menudo dicen: "¡Hacer clic una vez es suficiente!".

Supongo que podrías resolverlo buscando los mismos datos para ver si la publicación es única, pero me pregunto si hay otros métodos.

Por supuesto, esto no cuenta para los formularios web ASP.NET, porque POST no importa tanto.

Además de las muchas buenas técnicas ya mencionadas, otro método simple del lado del servidor, que tiene el inconveniente de requerir una sesión, es tener una variable de sesión que se desconecte en el primer envío.

La alteración del lado del cliente es una técnica común:

Desactivar botón de enviar
Cambia la pantalla a una pantalla de "espera por favor"
Si el formulario era modal, cambiar la pantalla a su proceso habitual (esto tiene el beneficio de hacer que las cosas se vean realmente resbaladizas)

Pero no es perfecto. Todo depende de que JS esté disponible y, si ese no es el caso, sin la detección de duplicación de back-end, todavía obtendrás duplicados.

Así que mi consejo es desarrollar algún tipo de detección entre bastidores y luego mejorar su forma para evitar que las personas con JS puedan enviarlas por duplicado.

La mayoría de las respuestas hasta ahora han sido del lado del cliente. En el lado del servidor, puede generar un campo oculto con un GUID cuando primero produce el formulario, y luego registrar ese GUID como un formulario enviado cuando se recibe la publicación. Verifíquelo antes de hacer más procesamiento.

Las técnicas del lado del cliente son útiles, pero es posible que desee acoplarlo con algunas técnicas del lado del servidor.

Una forma de hacerlo es incluir un token único en el formulario (por ejemplo, un GUID o similar), de modo que cuando procese el formulario, puede verificar si el token ya se ha utilizado, evitando una doble presentación.

En su caso, si tiene una tabla con visitantes del evento, puede incluir este token como columna.

Puede realizar un seguimiento del número de veces que se ha enviado el formulario y compararlo con el número de visitas únicas a la página con el formulario en la sesión.

Si bien las soluciones de JavaScript pueden deshabilitar el botón de enviar después de haber hecho clic en él, esto no tendrá efecto en las personas que tienen JavaScript desactivado. Siempre debe hacer que las cosas funcionen correctamente sin JavaScript antes de agregarlo; de lo contrario, no tiene sentido, ya que los usuarios aún podrán omitir las comprobaciones simplemente deshabilitando JavaScript.

Si la página donde aparece el formulario se genera dinámicamente, puede agregar un campo oculto que contenga algún tipo de número de secuencia, un hash o algo único. Luego tiene una validación del lado del servidor que verificará si ya ha ingresado una solicitud con ese valor único. Cuando el usuario envía el formulario, el valor único se compara con una lista de valores "usados". Si existe en la lista, es una solicitud engañosa y puede descartarse. Si no existe, agréguelo a la lista y procese de la forma habitual. Siempre que se asegure de que el valor sea único, esto garantiza que el mismo formulario no se puede enviar dos veces.

Por supuesto, si la página en la que se encuentra el formulario no se genera dinámicamente, entonces deberá hacerlo de la manera más difícil en el lado del servidor para verificar que la misma información no se haya enviado aún.

Una solución del lado del usuario es desactivar el botón de envío a través de Javascript después del primer clic.

Tiene inconvenientes, pero lo veo a menudo usado en sitios web de comercio electrónico.

Pero nunca reemplazará una validación real del lado del servidor.

Una solución solo para el cliente no será suficiente, como se indica en muchas de las respuestas aquí. Tienes que ir con un servidor a prueba de fallas.

Una razón que a menudo se pasa por alto que deshabilitar el botón de enviar no funciona es que el usuario simplemente actualice el objetivo de envío (y haga clic en Aceptar en el cuadro de diálogo "¿Está seguro de que desea volver a enviar los datos POST?"). O incluso, algunos navegadores pueden volver a cargar implícitamente la página enviada cuando intenta guardar la página en el disco (por ejemplo, está intentando guardar una copia impresa de una confirmación de pedido).

Casi nadie tiene js deshabilitado. Piense en codificar su sitio web de comercio electrónico para la mujer de 70 años que hace doble clic en cada enlace y botón. Todo lo que desea hacer es agregar un javascript para evitar que haga clic en "Solicitar ahora" dos veces. Sí, compruebe esto también del lado del servidor "estar a la defensiva", pero no codifique para ese caso. Pero por el bien de una mejor interfaz de usuario hacerlo también en el lado del cliente.

Aquí hay algunos scripts que encontré:

// // prevent double-click on submit // jQuery(''input[type=submit]'').click(function(){ if(jQuery.data(this, ''clicked'')){ return false; } else{ jQuery.data(this, ''clicked'', true); return true; } });

// Find ALL <form> tags on your page $(''form'').submit(function(){ // On submit disable its submit button $(''input[type=submit]'', this).attr(''disabled'', ''disabled''); });

Siempre que se solicite una página del servidor, genere un requestToken único, guárdelo en el servidor, marque el estado como NO procesado y páselo junto con la página solicitada actual. Ahora, cada vez que se envía una página, obtenga el requestToken de los datos de publicación "POST" y verifique el estado, guarde los datos o realice una acción alternativa.

La mayoría de las aplicaciones bancarias utilizan esta técnica para evitar el doble "POST". Por lo tanto, esta es una manera confiable y comprobada en el tiempo de evitar presentaciones dobles.

Ninguna de las soluciones se dirige a un servidor de equilibrio de carga.

Si tiene algún equilibrador de carga, enviar un UUID (o cualquier tipo de número único) al servidor para almacenar y volver a leer no funcionará bien si el servidor no conoce otros servidores, ya que cada solicitud podría ser procesada por un servidor diferente . Estos servidores necesitan leer / escribir en el mismo lugar.

Si tiene varios servidores, necesitará tener algún caché compartido (como Redis) entre los servidores para leer / escribir el valor único en el mismo lugar (lo que podría ser una solución de ingeniería avanzada, pero funciona).