Caducar página (con variables de sesión?)

[Borsetto]

Hola a todos!

Sé que hay varios temas acerca de cómo caducar páginas, pero después de mirarlos, sigo sin resolver mi problema.

El problema es el típico. Tengo un formulario que pide los datos de un libro. Al introducirlos y pulsar el botón de "Enviar", los escribe en la base de datos y muestra los valores en un panel. En este panel, tengo la opción "Eliminar". Si hago click en ella, el libro se borra de la base de datos, pero, y aquí viene el problema, si hago click en el botón "Atrás" del navegador me vuelve a escribir los valores del libro en la BD.

Sé, o supongo, que esto se puede controlar con variables de sesión, pero por más que lo estoy intentando no lo consigo. ¿Debo almacenar los valores del formulario en variables de sesión? ¿Debo hacer un session_destroy() nada más escribir en la BD? ¿Se deben borrar una por una las variables de sesión?

Cualquier ayuda será muuuuy bien recibida ;) Y en cuanto encuentre la solución, prometo postearla, para que otros novatillos como yo nos aclaremos con el asunto este.

Muchas gracias!!

[abimaelrc]

Para estos casos, lo mejor es separar el código de PHP del de HTML. Me refiero, creas una página que contenga solamente los formularios (tal vez lo necesario de PHP para mostrar informaciones) y la forma como debe verse la página. Luego creas totalmente aparte la de php para hacer las modificaciones en la base de datos sin enviar absolutamente nada al navegador. Al final cuando hagas todo el proceso solo tienes que redireccionar con header y al ejecutarse todo en el servidor, nada se envió al navegador. Por lo tanto cuando la persona presione el botón de atrás, solo verá los formularios y no el proceso que corrió en el servidor.

[Nekeniehl]

Con unset borras la variable

Código PHP:

  <?php 
// Inicializamos sesion 
session_start(); 
// Borramos la variable
unset ( $_SESSION['nombre'] ) {
// Borramos toda la sesion
session_destroy();
?>   

Suerte

[AnesGy]

Te sugiero que compruebes que los datos no estén ya en la base de datos.

[Borsetto]

Gracias a todos por contestar. Voy por partes:

AnesGy, (creo que) eso no me serviría, ya que cuando hago click en "Eliminar", estoy eliminando los datos de la BD, el problema reside en que al pulsar "Atrás", los valores los reenvía y los vuelve a escribir.

Nekeniehl, mediante este método he conseguido evitar que escriba en la BD al ir atrás, aunque aún tengo problemas que supongo podré depurar. Uno de ellos es el de redireccionar la página, me gustaría que, al ir atrás, no sólo escribiera, sino que siguiera mostrando el panel de libros. Sigo investigando por aquí y os cuento.

Y abimaelrc, creo que esa sería la opción más elegante, pero me está trayendo algunos problemas. Te importaría ponerme un ejemplo rápido de la estructuración que me comentas? Sobre todo para evitar ese famoso "headers already sent". De todas formas, antes te cuento. En mi proyecto, realmente no hay un formulario. Es una biblioteca, con una serie de libros online que, haciendo click sobre ellos, el usuario puede tomar prestados. Así pues, al hacer click en uno de ellos, aparece un mensaje de "Aceptación de Normas", y al aceptarlo, se graba en la BD y aparece el panel del usuario con los libros que tiene en préstamo. Realmente no sé cómo organizarlo para que al hacer una redirección con los headers no aparezca el "cannot modify headers - headers already sent".

De todas formas, voy a intentar solucionarlo con ambos métodos (sobre todo porque me pica la curiosidad y el saber de una vez por todas cómo funciona este tema). En cuanto lo tenga, os cuento.

Muchas gracias!!!

[abimaelrc]

Creas una página que contenga el formulario, ejemplo sencillo
--formulario.html

Código HTML:

<form action="modificarDb.php" method="POST">
<input type="text" name="txt" />
<input type="submit" value="submit" />
</form>
 

--modificarDb.php

Código PHP:

<?php
//creas condiciones y lo necesario para verificar los campos
if(!empty($_POST['txt'])){
    //añades la información a la base de datos, sin enviar información al navegador
    $conexion=......; //aquí va la conexión a la base de datos
    $db=......; //aquí va el seleccionar la base de datos
    $query = mysql_query('aquí va tu consulta') or die(mysql_error());
}
//redireccionamos
header('Location: formulario.html');
 

[AnesGy]

AnesGy, (creo que) eso no me serviría, ya que cuando hago click en "Eliminar", estoy eliminando los datos de la BD, el problema reside en que al pulsar "Atrás", los valores los reenvía y los vuelve a escribir.

Cual es el punto de hacer registros para eliminarlos después?

Otra cosa que puedes usar son claves, esto es usar un identificador que al usarse se guarde en la base de datos. Al reenviar el formulario se reenvía la clave otra vez, y como ya existe en la base de datos, entonces sabes que el formulario no se puede reenviar.

Hay muchas formas de hacer claves de este tipo. Puedes probar con uniqid, o con el timestamp, o incluso con alguna combinación de ambos o encriptaciones.

Luego tendrías que generar un sistema para que las claves caduquen y las puedas ir eliminando, pero eso ya es otra cosa.

[Borsetto]

Ummm... interesante, aunque sigo sin obtener lo que estaba buscando, pero creo que es por una mala estructuración del código. Ahora no puedo mirarlo, así que mañana por la mañana seguiré y os comento.

Muchas, muchísimas gracias por la ayuda. Os tendré informados.

[Borsetto]

Iniciado por AnesGy

Cual es el punto de hacer registros para eliminarlos después?

Otra cosa que puedes usar son claves, esto es usar un identificador que al usarse se guarde en la base de datos. Al reenviar el formulario se reenvía la clave otra vez, y como ya existe en la base de datos, entonces sabes que el formulario no se puede reenviar.

Hay muchas formas de hacer claves de este tipo. Puedes probar con uniqid, o con el timestamp, o incluso con alguna combinación de ambos o encriptaciones.

Luego tendrías que generar un sistema para que las claves caduquen y las puedas ir eliminando, pero eso ya es otra cosa.

Realmente, no es hacer registros para eliminarlos, es controlar lo que pueden y no pueden hacer los usuarios. Es decir, un usuario puede pedir prestado un libro; automáticamente, nada más aceptar las condiciones, le aparece un panel con sus préstamos y la opción de devolverlos. Luego en principio, un usuario puede grabar en la BD su préstamo, darse cuenta que no era el documento deseado, y devolverlo. Pero no debería volver a tomar prestado el documento si hace click en el botón "Atrás"... por intentar ser consistentes...

Lo de las claves puede ser una buena idea, pero creo que se aleja un poco de mi objetivo. Creo que sería un buen "parche" para un fallo de mi programa... En cualquier caso, mañana por la mañana seguiré viéndolo y os comento, ok?

Muchas gracias a todos!

[AnesGy]

abimaelrc propone hacer redirect, pero el redirect es un comando HTTP (lo que se manda antes de que se cargue la página).
Para hacer un redirect de ese tipo creo que hay que mandar el HTTPstatus de 204 No Content (osea documento vacío) para que no haya problemas. De todas maneras es hacer 2 conexiones, ya que el redirect lo hace el navegador, no el servidor, por lo que le esta diciendo al navegador que vuelva a enviar las peticiones pertinentes a tal página.

Esquemáticamente:

• Pulsas el botón
• El navegador envía la Petición HTTP (HTTP REQUEST), incluyendo los datos de POST.
• El navegador recibe los encabezados de Respuesta HTTP (HTTP RESPONSE Headers).
• Si tiene el HTTPStatus 204 (No content) no intenta bajar la página ya que el servidor avisa de que no hay contenido (ahorras un poco de tiempo).
• EL navegador lee el header Location: por tanto tiene que redirigirse a otro lugar.
• El navegador envía una segunda Petición HTTP, pero sin los datos POST.
• El navegador recibe una segunda lista de encabezados de Respuesta HTTP.
• Si esta bien diseñado el HTTPStatus será 200 (no hace falta espeficifarlo, es el que devuelve por defecto)
• Mostrar la página.

En principio si vuelves atrás volverás al formulario ya que la página intermedia no tiene contenido y no se guarda en el historial.
El único problema es que se envían dos HTTP Request.

El problema del otro es que tienes que quitar las claves viejas y diseñar la tabla y demás. Si no quieres complicarte mucho usa el header Location

[Borsetto]

Por cierto, una forma de evitar todo esto que estamos comentando, ¿no sería factible caducar la página de forma que muestre el siguiente mensaje?:

Advertencia: La página ha caducado

La página solicitada se creó utilizando la información que envió en un formulario. Esta página no está ya disponible. Como medida de precaución, Internet Explorer no volverá a enviarle la información.

Seguiré dándole vueltas....

[AnesGy]

Hum... Internet Explorer. XD

La idea de usar las claves era para que pudieras poner una página de caduado. No es un parche sino una medida de seguridad.

De todas maneras tu hablas de decirle a IE que la página está caducada y que IE se encargue de mostrar su mensaje. No te lo recomiendo. Confiar en el navegador es peligroso, mejor que el servidor devuelva un mensaje propio que dejar que el navegador interprete lo que le dices. La única manera de hacer las cosas como quieres es haciéndolas tu.

[Borsetto]

Mmmm.... me gusta eso del No Content..... me da una rabia enorme no poder verlo ahora, pero prometo que mañana os comento (en realidad sí que lo he visto un poco, pero me falla, es lo que tiene hacer las cosas deprisa). Mañana con más tiempo miro cómo funciona y os comento.

[Borsetto]

Un mes después, hago de nuevo aparición para comentar la solución que seguí. No conseguí que el famoso mensaje de "Página caducada" me apareciera cuando quisiera, pero sí he conseguido resolver mi problema.

Y al final, como ya me habías comentado, todo consistía en borrar la fuente de las variables a partir de las cuales la página volvía a escribir en la BD, ya fuera por GET o POST. Muy simple, quizá no lo mejor, pero funciona a la perfección.

Muchas gracias por vuestra ayuda