Código en el cliente / Código en el servidor
En Programando…: Prevenir múltiples submits Joaquín Bravo puntualiza mi anterior entrada sobre creación de formularios .
Efectivamente, el sistema no evita en todos los casos que se realice un doble submit. El cliente puede tener el javascript desactivado, para empezar. Y, en definitiva, evitar que se le realice a un cliente un doble cargo en su tarjeta de crédito es suficientemente importante como para controlarlo realmente. Joaquín nos proporciona una buena colección de enlaces para conseguir este control.
El sistema que yo proponía me sigue pareciendo válido para proporcionar “feedback” al usuario y evitar la tentación de pulsar dos veces, lo que siempre produce confusión en el usuario. Lo cual no quiere decir que si el doble submit es lo suficientemente peligroso se deba controlar en el servidor.
En cualquier caso, este es un problema que podríamos englobar dentro de un tipo más amplio: ¿Debemos programar algo en el cliente (javascript) o en el servidor (java, php, etc)?
Validaciones de formularios web, interacción con el usuario…
Las ventajas de la programación en el cliente son:
- Es una interacción más rápida con el usuario. Se puede validar inmediatamente un campo y no tener que esperar a que la petición le llegue al servidor y vuelva al cliente. Incluso se puede validar “conforme se escribe”, antes de que se pulse sobre el botón “enviar”.
- Mediante los eventos de javascript se puede conseguir una interacción más fina con el usuario, más cercana y en ocasiones igual a la que se puede conseguir con una aplicación cliente.
Las desventajas también son claras:
- Nada nos asegura que el cliente tiene activado el javascript.
- Nada nos asegura que el cliente interpretará adecuadamente el javascript que se le envía. Diferentes navegadores tienen incompatibilidades en el javascript que ejecutan y dichas incompatibilidades son mayores cuanto más “fina” es la interacción que queremos realizar.
- Desde un punto de vista de la seguridad, cualquier cosa que viene del cliente es insegura. No podemos fiarnos de una validación en el cliente.
Corresponde al programador decidir qué tipo de programación (de cliente o de servidor) es necesaria en cada momento. De hecho, en muchos casos lo que procede es una doble programación: Deberemos validar el formulario en el servidor (por seguridad y para asegurar el funcionamiento de la aplicación web) y también en el cliente para aumentar la usabilidad de la misma.
- Leer una llave desde una variable de sesión.
- Leer los datos del formulario, entre ellos, un campo que corresponde a la llave entregada por la sesión.
- Si es necesario volver a llenar data (por ejemplo, algún dato inválido) entonces se debe generar una nueva llave, almacenarla en la sesión y dibujar el formulario incorporando esta nueva llave como un control type="hidden".
- Si todos los datos son válidos, entonces debemos verificar la llave: si la llave obtenida por parámetros es distinta a la llave de la sesión, tenemos un doble submit. Si no, podemos proceder a efectuar la operación del formulario.
En mi aplicación, cuando tengo que lidiar con un doble submit bajo este esquema, usualmente ignoro el hecho y muestro el resultado de la operación como válida. Esto puede no ser aplicable a todos los casos, pero en un escenario simple (por ej., una entrada a un foro de mensajes) debiese bastar.
Espero no haberme equivocado en la descripción :-)
Por temas de usabilidad y rendimiento (¿porque esperar a que un error llegue al servidor?) implementarlo en JavaScript.
Y sobre todo por temas de seguridad hay que tambien comprobarlo en el servidor. ¡¡¡No te puedes fiar¡¡¡ es muy sencillo manipular el envio de datos saltandose el JavaScript de validación.
Y para terminar, este post me recuerda este otro de "entornos abiertos":
http://www.abelgonzalez.com/entornosabiertos/los-peligros-de-pasar-de-todo-por-get_p139.html
que viene muy a cuento al tema. Habla sobre los peligros de enviar los datos por GET con un ejemplo real. Aunque los enviasen por POST sería muy fácil simular el mismo resultado.
A mi no se me queda claro porqué necesitas generar una nueva llave cuando el formulario se debe rectificar por un fallo de datos.
Por otro lado, el problema de asociar la llave a la sesión del usuario es que el usuario podría intentar hacer un proceso en paralelo. Ejemplo, el usuario, abre dos ventanas de formulario en dos ventanas distintas que comparten la misma sesión (utilizando el botón shift al clickar en el enlace). Con ese esquema de una sola llave generada por sesión, esto no funcionaría. Una ampliación de eso es tener dos listas asociadas a la sesión: Una lista de llaves entregadas (utilizadas en el formulario) y otra lista de llaves usadas (llaves para las que ya se ha realizado un submit).
Un saludo.
Comentarios cerrados para este artículo