Problema Integridad BD - Formularios POST

[C_Cornell]

Bueno el caso es que tengo varios formularios POST que al enviar realizan operaciones en la BD.

El problema es que: Si envío el formulario y se realiza la operación, el usuario puede retroceder a la página de confirmacion del envío del formulario y duplicar ( o N-plicar ) la operación en la BD!

Decir que la pagina del formulario y la página de la operacion es la misma, con un bloque condicional tipo:

Código PHP:

  if(isset($_POST['confimacion'])){

     //operaciones BD

}  
   

Pero aunque ponga una pagina PHP intermedia a la manera de:

pagina Form -> pagina Operaciones (redirecciona) -> pagina visualizacion resultados

Siempre se podría volver a la página donde se envía el formulario.

Con IE puedo hacer expirar la página anterior (aunque el usuario se quede en un callejón sin salida) En Firefox, la página anterior se recarga igualmente.

Total que no se como lo veis. Supongo que es un problema habitual pero como no tengo experiencia no se como se soluciona. En fín un saludo

[jaronu]

Hola

podrias borrar las variables post antes de cargar el form, o hacer comprovaciones con IF para que no se dupliquen datos.

Un saludo

[Keysher]

Usa variables de sesión. Si se han hecho las operaciones, crea una variables, que será la que compruebes en el script, de éste modo podrá enviar el formulario las veces que quiera, que no se tendrá en cuenta hasta que expire la sesión.

[masterojitos]

puedes la primera vez guardar en session un contador el cual al iniciar esta en cero(0) y al ejecutar el post, lo incrementas.... solo preguntarias que ejecute el script si es menor o igual a 1.

las otras vecez, la variable se session sera mayor que 1 y no ejecutara el script.

suerte.

[C_Cornell]

Si... me gusta por donde vas, Keysher y masterojitos

Pero me pregunto una cosa, esa variable SESSION que digamos ("deshabilita" la operaciones BD resultantes del envío del formulario) que ámbito tendría???

Por ejemplo:
- Inserto un nuevo "cliente" en el sistema
- Si la operacion en la BD se realiza correctamente establezco la variable session que impide duplicar la operacion.
(solucionado pero... si ahora quiero insertar otro cliente???)
- Voy a "nuevo cliente"
- Elimino la variable session que me inhabilita el formulario y me muestra el form vacio
(hasta aquí todo bien pero...)
El usuario puedo retroceder 'n' paginas con el navegador y llegar a aquella pagina de confirmación en la que se envío el primer form y ahora Si, encontrarse que puede repetir la operación que antes hemos impedido repetir.


Vamos que no se, si hay una estrategia mas claro en estos casos.

[Deschamps]

Iniciado por C_Cornell

(hasta aquí todo bien pero...)
El usuario puedo retroceder 'n' paginas con el navegador y llegar a aquella pagina de confirmación en la que se envío el primer form y ahora Si, encontrarse que puede repetir la operación que antes hemos impedido repetir. Vamos que no se, si hay una estrategia mas claro en estos casos.

No sé si te servirá (yo creo que sí), pero por echar un vistazo a este hilo no pierdes nada.

Un saludo.

[C_Cornell]

Deschamps entiendo bien tu estrategía del hilo que pusiste. Pero le veo un fallo a tu solución (o lo estoy enfocando mal?)

Vamos a ver si me explico:

Que le impide al usuario de tu aplicacion, retroceder (mediante el navegador) desde la pagina de "resultado.php" hasta "formulario.php"???

Porque si lo hace, se volvera a ejecutar la funcion de validación y se volverá a poner a TRUE la variable $_SESSION['validado'], te redigirá a "resultado.php" y te hará las operaciones de nuevo, no?

[masterojitos]

Iniciado por masterojitos

puedes la primera vez guardar en session un contador el cual al iniciar esta en cero(0) y al ejecutar el post, lo incrementas.... solo preguntarias que ejecute el script si es menor o igual a 1.

las otras vecez, la variable se session sera mayor que 1 y no ejecutara el script.

suerte.

[Keysher]

Usa JS para vaciar el formulario antes de mandarlo.... No sé si funcionará, pero es lo único que veo viable.

De todos modos tendrás el mismo problema si le da por meter otra vez los mismos datos al ir a dar de alta un nuevo cliente....

[jaronu]

No se , veo mas viable que en este proceso

pagina Form -> pagina Operaciones (redirecciona) -> pagina visualizacion resultados

en pagina Operaciones o en pagina visualizacion resultados despues de usar las variables POST las borre

Un saludo

[C_Cornell]

Si, cierto. Antes estaba un poco despistado...

Pero aún así le veo un problema a tu solución;

Imaginemos que es una operacion de insercion en la BD, con clave primario autoincrementar.

Bueno no queremos logicamente introducir repetidas veces los mismos datos.
Y tu solucion lo evita.

Pero ahora yo digo: Voy a insertar otro registro diferente al anterior!

Entonces habría que poner esa variable SESSION a cero, no? Para poder insertar otro registro.

Ahora estoy rellenando el nuevo formulario y va y me arrepiento!! Y me da por retroceder con el navegador hasta la 1ª insercion... Y me deja re-enviarlo porque se encuentra la variable a cero....

Jaja vamos soy un rallado, me diras. Logicamente yo que soy el administrador no haría eso, pero claro, un usuario malintencionado podría...

[C_Cornell]

Si, eso de borrar las variables POST ya lo probé, pero cuando vuelve atras retrocediendo con el navegador ( el firefox, al menos, te da la opcion de retroceder con las variables POST que "había entonces" y te las carga igualmente aunque las halla borrado "YO" despues de la operacioin BD)

Keisher, si tienes razon con lo de que tengo el mismo problema si en una nueva inserción le da por meter los mismos datos. Pero bueno el caso de la insercion era para hacerse una idea. Tengo formularios en los que se liga un elemento1 con otro elemento de un lista. Pero la segunda vez solo te visualiza los elementos con los que aun no está ligado. Vamos que creo "registros relacion" mediante formularios y las listas siempre son acordes a las restricciones de mi sistema y la informacion actual en BD. Así que me cunde solucionar el problema porke no kiero que el elementoA este relacionado con elementoB mas de una vez, por ejemplo

[Keysher]

¿Y si en la página del formulario generas un campo aleatorio con la fecha y hora de cuando se mostró la página? Luego al ir a insertar los datos compruebas ese campo con la fecha y hora actual..

Si ha ido hacía atrás y no se recarga la página no se modificará ese valor...

De todos modos es un tema complicado, ya que si el usuario tarda media hora en rellenar los datos no le dejará dar de alta al nuevo cliente...

¿Has probado lo que comentaba antes? si antes de mandar el formulario vacias los campos, puede que al volver atrás aparezca el formulario vacio..... O desactivando el botón de enviar...

Edito:
Cuando digo borrar, me refiero ANTES de enviar los datos, aunque esto incluiría jugar un poco con JS.

[jaronu]

Intenta borrandolas despues de usarlas Y antes de cargar el form

un saludo

[Keysher]

Una variante de lo que había planteado antes:

Cuando generes el formulario HTML, en un campo oculto genera un valor alfanumerico aleatorio. Cuando insertes los datos en la BDD asigna ese valor a una variable de sesión.

Si se vuelve hacía atrás y se intenta dar de alta el mismo usuario, ese valor será igual! así que antes de meter los datos en la BDD compara el campo oculto con la variable de sesión...

[jaronu]

Pero cuando de atras ¿no cambiara el valor alfanumerico generado en el form?

podria borar la variable asi por ejemplo

unset($GLOBALS['email']);

[Keysher]

Si no se recarga la página, no. El valor lo generamos desde PHP.

Si se recarga la página no hay problema, porque los campos del formulario estarían vacíos.

[C_Cornell]

la opcion JS no es viable.

A -> (post1) -> (B) -> (JS) -> B* -> (post2) -> (C)

B es el form
B* es el form con los campos vacios o con la deshabilitacion de enviar
C es la pagina donde se hacen las operaciones

El caso es que si retrocedo con el navegador desde C, lo que me carga es B, basado en $_POST = (post1)

Así que da igual que borrara los campos o deshabilitara el boton en B*

No regresas a B* la pagina se carga de nuevo en la version B

[jaronu]

Una cosa, nunca sabemos de que son tus forms

por ejemplo si es un form de registro,basta con comprobar si el user y su email existen o no en la BBDD y no dejas ingresar lo datos ya ingresados, pero de que son los forms, por que podrias hacer algo parecido.

Un saludo

[Keysher]

A mi a falta de probarla me gusta mi última propuesta.....

Con dos inconvenientes:

- Si ha dado de alta varios clientes y va hacía atrás varias veces y pasa por varios formularios... puede que le deje volver a dar de alta el que no se ael último. No sé como funcionan los navegadores, tal vez sólo guarden el último formulario... De todos modos esto se podría solucionar guardando en un array todas las cadenas aleatorias y comprobarlas.

- Segundo inconveniente, y más grave: si se da de alta a un cliente y el usuario pincha hacía atrás para dar de alta a otro diferente, no le dejará!

[Keysher]

Jaronu, había pensado en ello, pero teniendo en cuanta que el ID es autonúmerico.. supongo que puede haber dos clientes con el mismo nombre, la única que le quedaría sería comprobar TODOS los datos para que no sean exactamente iguales.

[jaronu]

pues eso dije, dos nombre iguales (si son niks no deberia haber dos iguales) los podria haber en la BDD, pero ya dos emails iguales , es improbable.

Un saludo

[Keysher]

Estoy de acuerdo en que la comprobación debería ser a la hora de insertar los datos, es mucho más limpio (lo dejaba entrever en mi segundo mensaje), pero me gusta teorizar en como se podría evitar la situación que propone!

[C_Cornell]

No no, en el caso en el que estoy no se trata tanto de insertar registros sin mas en el sistema, ya que eso si que lo compruebo datos como: dni o nombre.

El caso es una aplicacion de un instituto

Por ejemplo el alta de un alumno en una asignatura.

1 - Elijo al alumno del sistema en el formulario
2 - El formulario se recarga y me deja escoger ahora las asignaturas que puede escoger teniendo en cuenta (el curso o titulacion que estudia y que no este ya dado de alta en la asignatura) Vamos, que me muestra un listado de asignaturas teniendo en cuenta las restricciones que existen en mi sistema
3 - Valido (datos adicionales) del form
4 - Si correcta validacion -> pagina de operaciones, etc, etc

Luego si quiero añadir otra asignatura al alumo, no me mostraria en la lista de asignaturas la asignatura que añadimos anteriormente porque solo elaborar el listado adecuado en cada momento.

El problema es si navego en el broser hacia atras y vuelvo a la pagina donde confirmo, por ejemplo: Diego - Fundamentos de programación

Porque podria vincular al tal diego mil veces con una asignatura

Y me direis, que eso deberia comprobar en la funcion de validacion, pero me he currado lo de que en cada formulario salga ya la informacion restringida, cuando se trabaja con select en listados...

No sé chicos... no sé

[Keysher]

De todos modos, la validación también debería comprobar que no se pueda asignar dos veces la misma asignatura al mismo alumno (incluso sería la propia BDD la que diría que no al intentar duplicarlo).

No digo que esté mal intentar controlar el envio del formulario, pero esa comprobación nunca debe evitar la validación antes de introducir los datos, por muy seguro que se esté de que han venido bien.

[jaronu]

Si, estoy con Keysher, debe habere ese tipo de validacion de alumno asignatura y por mas que reenvies el form 1000 veces no hara la insercion en la BBDD.

Yo de hecho para un sistema de alumnos y cursos que realice, nunca me dejaba asignar a un mismo nombre un mismo curso.

Un saludo

[C_Cornell]

Si, si... pero... en fin... es una carga importante de comprobaciones (y trabajo ) que tengo que hacer (dado la extension del sistema), cuando lo único que haria falta seria no poder repetir el envío de un formulario ya enviado....

Deberia haber una solucion...

[Keysher]

Si sólo quieres evitar que se envíe un formulario ya enviado, puede que te sirva con la opción que propuse de meter en un campo oculto una cadena aleatoria.

Pero esto te impediría mandar ese formulario aunque se cambien los datos para que se algo legitimo.

[jaronu]

pero si alguien comete un error y pone un alumno con una asignatura que ya tiene, estaras en las mismas, y no tiene que ser dando atras en el navegador, podria ser otro dia.

Pienso que es mejor las comprovaciones, creo que no tienes mas remedio.

para eso dijistes

Jaja vamos soy un rallado, me diras. Logicamente yo que soy el administrador no haría eso, pero claro, un usuario malintencionado podría...

[C_Cornell]

Por eso me da pereza ampliar las funciones de validacion, porke los formularios son a prueba de errores. No se podria volver a añadir un alumno a una asignatura si rellenas un formulario, no te puedes ekivocar porke las opciones que no seria correctas no te las muestran. Son formularios con select´s que se cargan con las opciones adecuadas! En unico problema es con el reenvio!

De todas formas, me habeis convencido, ampliaré las funciones de validacion.

Pero aun así quiero saber como se podría evitar el reenvio del formulario. Jaja
Ahora es algo personal!