Foros del Web » Programando para Internet » PHP »

Evitar "Advertencia: La página ha caducado" al usar formularios

Estas en el tema de Evitar "Advertencia: La página ha caducado" al usar formularios en el foro de PHP en Foros del Web. ¿Cómo hacer para evitar lo siguiente? el escenario es este: 1. El usuario se autetifica e inicia sessión. 2. En alguna de las páginas del ...
  #1 (permalink)  
Antiguo 15/06/2006, 17:32
Avatar de rod524  
Fecha de Ingreso: agosto-2004
Mensajes: 517
Antigüedad: 13 años, 4 meses
Puntos: 0
Evitar "Advertencia: La página ha caducado" al usar formularios

¿Cómo hacer para evitar lo siguiente?

el escenario es este:

1. El usuario se autetifica e inicia sessión.
2. En alguna de las páginas del sitio el visitante llena un formulario y lo envía.
3. El usuario sigue navegando por el sitio.
4. Al usar los botones de "Atrás" y "Adelante" del navegador, si se regresa a la página en que el usuario envió la información del formulario aparece una página de advertencia:


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.

Para volver a enviar la información y ver esta página Web haga clic en el botón Actualizar .
que en una sessión iniciada, al tener que llenar un formulario


Cuando el formulario se encuentra en una página HTML no causa esto, sólamente al usar un formulario dentro de una sesión PHP iniciada, donde se retoma las sesiones con session_start().

Supongo que ha de ser un detalle pequeño para solucionarlo, pero no se me ocurre como.

Saludos.

Última edición por rod524; 15/06/2006 a las 19:05
  #2 (permalink)  
Antiguo 16/06/2006, 07:53
O_O
 
Fecha de Ingreso: enero-2002
Ubicación: Santiago - Chile
Mensajes: 34.417
Antigüedad: 15 años, 11 meses
Puntos: 126
El problema que observas es ocasinado por qué el uso de sesiones común de PHP por defecto ajusta el control del caché de páginas (para navegadores/proxys y demás ..) a un valor "no caché" (no hacer caché de la página que queda bajo sesines) .. Es un tema de "seguridad" no hacer caché de páginas que quedan "protegidas" por una sesión.

Esto en combinación con tus formularios que usan método POST originan que al ir hacia -atras- con tu navegador .. el mismo pretenda enviar los mismos datos que tiene almacenado a la página/script en cuestión.

Algunas soluciones para evitar este "problema".

1) Que tu aplicación guie al usuario en el flujo de tus páginas. En resumen, que "no" tenga que usar dichos botones por qué tu aplicación no lo guía (con links, menus claros .. etc). En ese caso .. el mensaje aparecerá igualmente .. pero es completamente que -deba- aparece por seguridad. Si tu aplicación guía al usuario .. en ningún momento nadie debería ver ese mensaje y si lo vé es por qué "intencionalmente" no está siguiendo el flujo de tu aplicación.

2) Usar método GET en tus formularios .. nada recomendable, quedarán esos datos en los historiales de los navegadores ..

3) Forzar a PHP a que en su uso de sesiones haga el caché de páginas. Puedes usar la función:

session_cache_limiter() y lo ajustas a un valor tipo "public" o similar (lee los comentarios de los usuarios de dicha función.

www.php.net/session_cache_limiter

Un saludo,
__________________
Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo.
  #3 (permalink)  
Antiguo 16/06/2006, 10:39
Avatar de rod524  
Fecha de Ingreso: agosto-2004
Mensajes: 517
Antigüedad: 13 años, 4 meses
Puntos: 0
Muchas gracias por tu respuesta Cluster.

Ahora sólo queda otra pregunta:

¿Puede esto ocasionar alguna vulnerabilidad al manejo de la información enviada desde el formulario?

asumiendo que los demás puntos de seguridad ya han sido considerados, autentificación, validación de entradas etc,.

Saludos.
  #4 (permalink)  
Antiguo 16/06/2006, 11:00
Avatar de GatorV
$this->role('moderador');
 
Fecha de Ingreso: mayo-2006
Ubicación: /home/ams/
Mensajes: 38.567
Antigüedad: 11 años, 6 meses
Puntos: 2122
Otra opcion, es usar una cabecera de Location para una vez terminado de enviar el file se vaya a la pagina que quieres por decir:

formulario.php -> procesa.php (redirigir via cabecera) -> resultado.php

para redirigir usa:
Código PHP:
header"Location: nueva_pagina.php" ); 
asi cuando esten en resultados.php, si le dan Back, se van a formulario.php, ya que el historial del browser es: formulario.php -> resultados.php.
  #5 (permalink)  
Antiguo 16/06/2006, 12:32
O_O
 
Fecha de Ingreso: enero-2002
Ubicación: Santiago - Chile
Mensajes: 34.417
Antigüedad: 15 años, 11 meses
Puntos: 126
Cita:
Iniciado por GatorV
Otra opcion, es usar una cabecera de Location para una vez terminado de enviar el file se vaya a la pagina que quieres por decir:

formulario.php -> procesa.php (redirigir via cabecera) -> resultado.php

para redirigir usa:
Código PHP:
header"Location: nueva_pagina.php" ); 
asi cuando esten en resultados.php, si le dan Back, se van a formulario.php, ya que el historial del browser es: formulario.php -> resultados.php.
También es necesario (no vimos el código que usa nuestro amigo para trabajar el proceso de datos de un formulario .. ).

Un saludo,
__________________
Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo.
  #6 (permalink)  
Antiguo 16/06/2006, 12:35
O_O
 
Fecha de Ingreso: enero-2002
Ubicación: Santiago - Chile
Mensajes: 34.417
Antigüedad: 15 años, 11 meses
Puntos: 126
Cita:
Iniciado por rod524
Muchas gracias por tu respuesta Cluster.

Ahora sólo queda otra pregunta:

¿Puede esto ocasionar alguna vulnerabilidad al manejo de la información enviada desde el formulario?

asumiendo que los demás puntos de seguridad ya han sido considerados, autentificación, validación de entradas etc,.

Saludos.
mm .. Seguridad ... mm ...

Si la conexión no pasa por SSL .. (segura .. https://) .. podrías tener problemas si te "capturan" los datos en la comunicación entre cliente-servidor (pues viajan -no encriptados- como texto plano fácilmente legibles ...) ..

Por eso el uso de sesiones entre otras cosas y por defecto suele ajustar las cabeceras de "no caché" para que no se haga caché de esa página.

Un saludo,
__________________
Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo.
  #7 (permalink)  
Antiguo 16/06/2006, 13:44
Avatar de rod524  
Fecha de Ingreso: agosto-2004
Mensajes: 517
Antigüedad: 13 años, 4 meses
Puntos: 0
Gracias nuevamente,

Checaré la parte de seguridad, dado que esto será para un sistema de e-commerce, como alternativa a SSL estoy considerando el uso de los formularios en flash, usando swf con AS encriptado y un algoritmo para envío de información por POST con los datos concatenados a una sola variable y encriptados también, posiblemente esto resuelva algunos puntos sobre seguridad.

Saludos y gracias.
  #8 (permalink)  
Antiguo 16/06/2006, 15:32
O_O
 
Fecha de Ingreso: enero-2002
Ubicación: Santiago - Chile
Mensajes: 34.417
Antigüedad: 15 años, 11 meses
Puntos: 126
Cita:
Iniciado por rod524
Gracias nuevamente,

Checaré la parte de seguridad, dado que esto será para un sistema de e-commerce, como alternativa a SSL estoy considerando el uso de los formularios en flash, usando swf con AS encriptado y un algoritmo para envío de información por POST con los datos concatenados a una sola variable y encriptados también, posiblemente esto resuelva algunos puntos sobre seguridad.

Saludos y gracias.
No te lies con soluciones a medias. Usa SSL .. es un standard de seguridad .. sobre todo si hablas de un sitio de "e-commerce" .. a mi como futuro usuarios potencial de tu sistema me interesaría "seguridad y confiabilidad" .. eso lo dá el SSL y sus correspondientes certificados para tu dominio donde ejecutes tu aplicación.

Si "encriptas" de esa forma estará en el cliente la "semilla" o algoritmo de encriptaciones que uses ya sea: en tu SWF .. en algo en javascript .. en general estará en manos de quien quiera empezar a realizar "ingenería inversa" .. Con más o menos tiempo lo sacaran.

Y .. por lo demás seguiras requiriendo el certificado SSL otorgado por algún organismo acreditado para dar "confiabilidad" a tu sitio de e-commerce.

Un saludo,
__________________
Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo.
  #9 (permalink)  
Antiguo 16/06/2006, 17:03
Avatar de rod524  
Fecha de Ingreso: agosto-2004
Mensajes: 517
Antigüedad: 13 años, 4 meses
Puntos: 0
Tienes razón Cluster, creo que estaba debrayando pensando en la parte estética del asunto.

Saludos.
  #10 (permalink)  
Antiguo 31/07/2006, 18:28
 
Fecha de Ingreso: agosto-2004
Mensajes: 79
Antigüedad: 13 años, 4 meses
Puntos: 0
Pregunta Y que pasa con la seguridad?

Hola, se que es un tema viejo, pero en cunto a utilizar session_cache_limiter en public , qué pasa con la seguridad? no se vuelve vulnerable la aplicación?
He estado leyendo en la página de php, pero no hablan explicitamente sobre esta situación. Si al usar sesiones cambian el parámetro a no caché y nosotros los cambiamos estamos echando atrás ese aspecto en la seguridad.

Por favor explíquenme un poco. Gracias
  #11 (permalink)  
Antiguo 31/07/2006, 20:16
O_O
 
Fecha de Ingreso: enero-2002
Ubicación: Santiago - Chile
Mensajes: 34.417
Antigüedad: 15 años, 11 meses
Puntos: 126
Lo mejor es que hagas tus pruebas. Y sobre todo que pienses el problema no desde "sesiones" o busques información explicita en manuales de "sesiones" .. hay temas como este que no son directos de "sesiones" pero sí de otras técnicas o comportamientos de "clientes" (navegadores .. etc).

El control del caché según lo permitas o no lo que te hará es que quede tu página en cachés de navegadores y proxys en general .. por ende su "contenido" podrá ser visto desde esas caché's. Lo ideal es que NO quede. .. aunque el sistema de sesiones en sí y tus validaciones ya actuaran si .. por ejemplo caes en una página con un formulario e intentas interactuar con el .. (tu sesión no será válida y actuaran tus validaciones basadas en sesiones).

Un saludo,
__________________
Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo.
  #12 (permalink)  
Antiguo 01/08/2006, 08:43
 
Fecha de Ingreso: agosto-2004
Mensajes: 79
Antigüedad: 13 años, 4 meses
Puntos: 0
MI caso sobre session_cache_limiter

Gracias por tu respuesta.

Pero tengo otro interrogante. ¿Probé con session_cache_limiter('public') y soluciona el problema de ir atrás, pero si me devuelvo y cambio los datos, mis datos en los formularios, mis variables de session no se actualizan y permanecen con los valores iniciales.

Mi aplicación es el de una inscripción típica paso a paso, de una página a otra captura lo que viene del post y guardo mis variables de session. El problema es que si uso session_cache_limiter('public') mis variables de sesion siempre quedan con los datos de mi primer proceso de inscripción. Esto encaso de que haga varios procesos. Si quito la instrucción session_cache_limiter('public') todo funciona bien con las variables, pero vuelve el problema del paso atrás.

La recomendación de usar header("location ...") a la página sicen que tiene problemas de seguridad. Entonces que resta hacer.
  #13 (permalink)  
Antiguo 01/08/2006, 09:17
O_O
 
Fecha de Ingreso: enero-2002
Ubicación: Santiago - Chile
Mensajes: 34.417
Antigüedad: 15 años, 11 meses
Puntos: 126
La recomendación de usar header("location ...") a la página sicen que tiene problemas de seguridad.

Quien dice que tiene problemas de seguriad redireccionar así?

Mientras que tu valides tus variables de sesión .. redireccionar y que no se "llegue" donde se indica es lo de menos. El caso es que tu código NUNCA se ejeuctará por qué tu ya lo validaras .. ahora .. el flujo de la aplicación no será guiado por donde corresponde .. pero problema de seguridad no lo veo claro al respecto.

Un saludo,
__________________
Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo.
  #14 (permalink)  
Antiguo 01/08/2006, 10:17
 
Fecha de Ingreso: agosto-2004
Mensajes: 79
Antigüedad: 13 años, 4 meses
Puntos: 0
ok gracias por la aclaración
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 19:44.