Evitar que las páginas se guarden en el historial de navegación

[[Héctor Randolph]]

Hola a todos

Me gustaría saber si existe alguna forma de evitar que los script que ejecuto dentro del entorno de mi aplicación web se guarden en el historial del navegador de internet.

He tomado precauciones para validar los permisos de un usuario al acceder a las páginas y también con respecto a la caducidad de las sesiones. Sin embargo, considero que sería bueno que algunas páginas críticas o restringidas no se guarden en el historial.

Estoy usando PHP 5.2.2 en un servidor Apache 2

Agradezco desde ahora cualquier aportación.

Saludos

[dec]

Hola,

No sé si voy a decir una tontería. Hasta donde yo llego un script PHP nunca se "guarda" en el cliente. Como mucho podrá "cachearse" su resultado, pero, no el propio script. ¿Qué quiero decir con esto? Pues que, cuando el script se ejecute, ofrecerá el resultado que el script quiera, no el que el navegador "guardase" antes.

Existen cabeceras HTTP para indicar que no se guarde en caché el resultado de nuestro script. Pero, estas serán cuando menos problemáticas, puesto que al cabo dependerá del cliente (navegador) guardar o no el resultado del script en cuestión. Por tanto no podríamos fiarnos de estas cabeceras, aunque es cierto que existen, y, me consta que se usan.

Tal vez sea lo único que pueda hacerse. Buscar información acerca de estas caberas HTTP y utilizarlas. En cualquier caos, no me queda del todo claro cuál es el problema, dónde están esas "páginas críticas o restringidas", qué es lo que las hace críticas y restringidas. Cómo es posible que alguien pudiera llegar a ellas desde el caché del navegador.

Vale. No he respondido absolutamente nada. Pero lo he intentado, ¿eh? Y he dado un empujoncito a este hilo a ver si algún otro compañero, ¡tú mismo!, puede aportar alguna otra cosa para ayudar con este asunto.

[keyboy]

Usa una sóla página, carga todo lo demás con ajax y olvídate del historial

Bye

[dec]

Hola,

Empezado por keyboy

Usa una sóla página, carga todo lo demás con ajax y olvídate del historial

Pero el historial es bueno, es nuestro amigo.

Y lo cierto es que hay aplicaciones "Ajax" que tienen que "imitar" al historial...

[keyboy]

No. Si yo estoy de acuerdo contigo, pero bueno, él quiere no tener historial

La verdad es que sería mejor si Héctor nos describiera con más detalle una situación en la que quiera omitir páginas del historial para poder saber si sería realmente lo adecuado o qué alternativas pueda haber.

Bye

[[Héctor Randolph]]

Antes que nada gracias por responder

Empezado por keyboy

Usa una sóla página, carga todo lo demás con ajax y olvídate del historial

Bye

Efectivamente, eso se puede hacer, tengo varios scripts que funcionan de esta forma, solamente buscaba una manera más directa de hacerlo para toda la aplicación.

Encontré que uno de los parámetros de los popups de Javascript es copyhistory=no, pensé que esta función me ayudaría,sin embargo, no funciona.

function abrir(theURL) {

var windowprops ="top=0,left=0,toolbar=no,location=no,copyhistory=no,status=no,menubar=no,scrollbars=yes, resizable=yes,width=800,height=800";
window.open(theURL,'_mi_ventana',windowprops);
}

Empezado por Dec

no me queda del todo claro cuál es el problema, dónde están esas "páginas críticas o restringidas", qué es lo que las hace críticas y restringidas. Cómo es posible que alguien pudiera llegar a ellas desde el caché del navegador.

Hola David, solo por dar algún ejemplo, el usuario abre una sesión y dentro del sistema visita varias subpáginas, una de ellas recibe pagos por medio de tarjeta de crédito, otras muchas en dónde se permite el acceso solamente a usuarios autorizados y otras tareas más. En el historial del navegador va quedando huella de todas estas páginas por ejemplo:

http://www.sitio.com/area_restringida/altas.php
http://www.sitio.com/cobro.php?id_doc=2323

El personal de sistemas en la empresa que nos compró la aplicación considera que estas páginas no se deben guardar en el historial, ya que eventualmente los usuario intentarán abrirlas nuevamente.

Ya les expliqué que una vez que las páginas hicieron su función no podrán ejecutarlas nuevamente, y mucho menos abrirlas sin autorización, pero la cuestión es que no quisieran verlas en el navegador. De hecho tuve que ocultar los botones de navegación, pero no es suficiente, quieren que las páginas visitadas dentro de la aplicación no se vean en el historial.

En este momento, no estoy seguro de que se puedan ocultar las páginas del historial, pero si alguien sabe algo les agradecerá su ayuda.

Saludos

[dec]

Hola,

Tiene lógica lo que dices. Efectivamente, poco importa que una página esté en el historial, que no es lo mismo que el caché, cuando se visite de nuevo, siempre se ejecutará el correspondiente script, que comprobará si el usuario está autenticado, etc.

Ahora bien, ¿cómo hacer desaparecer del historial las páginas visitadas? Yo diría que no es posible. Y, aunque le encuentro sentido, por otro lado, puede que en esto se quiera ser más papista que el papa. Ahora bien, si es algo "obligatorio", pues entonces el compañero keyboy ha apuntado una posible solución.

Un tema interesante. Reconozco que nunca me informé de ello. No me suena que pueda hacerse algo así, el historial lo gestiona el cliente, y, cada cliente es un mundo, pero, no digo que no pueda hacerse, y sería interesante ver cómo y de qué manera.

[Julián]

Jau!

Este problema de Hector tiene una solución facilisma: la mejor forma de que las url's desaparezcan del historial es que nunca se hayan guardado en el. ¿Cómo? pues muy fácil. No usando el metodo GET, así de sencillo.

Por ejemplo, el típico formulario para poner el usuario y la contrseña, o el que envía los datos de una tarjeta, o cualquier información medianamente sensible. Esos datos es mejor enviarlos vía POST, usnado un formulario, y asi no quedan guardados en el historial.

Esto, en realidad, no es un problema de seguridad. Es mas una cuestión de estetica y comodidad, y de sentido común.

Una url de un hipotético sistema de noticias, como:
http://server/noticias/ha_salido_delphi2008_y_es_gratis
está clarisimo que es el tipo de dirección que conviene que pueda ser guardada en el historial. Si usamos AJAX para un sistema así, y perdemos la ventaja que supone el disponer de url's amigables como esa, pues estamos haciendo el tonto. O el tonto perdío.

Supongamos que queremos ver los datos del pedido 3465. ¿que es mejor?
¿una url como http://server/tiendaonline/pedidos/3465 en la que poder hacer click, o un form con un input o un select, y un botón que envie el nº pedido vía POST ?

Gueno, creo que me explicao, mas o menos, creo.

¡Perrea, perrea!

[[Héctor Randolph]]

Hola Julián

Bien, ahora me queda claro que es una cuestión que puedo manejar a conveniencia con el método POST. Es cuestión de determinar cuales scripts serán tratados de esta manera para que no aparezcan en el historial.

Solamente falta ver que hago con algunas páginas que mando llamar directamente con la función header("location:url").

Gracias a todos por su ayuda.

[Julián]

Empezado por Héctor Randolph

Solamente falta ver que hago con algunas páginas que mando llamar directamente con la función header("location:url").

Bueno, no lo he comprobado, pero habría que ver si las url's llamadas con la función Header() se guardan en el historial. En caso de ue así fuera pueeds hacerte una funcion alternativa que pida la url vía post. Así, a lo bestía se me ocurre una chapuza consistente en armar un form y un poquito de javascrit que haga un submit.


¡Perrea, perrea!

[keyboy]

Empezado por Julián

Supongamos que queremos ver los datos del pedido 3465. ¿que es mejor?
¿una url como http://server/tiendaonline/pedidos/3465 en la que poder hacer click, o un form con un input o un select, y un botón que envie el nº pedido vía POST ?

GET, desde luego.

GET para pedir datos, POST para poner datos.

Bye

[dec]

Hola,

En el objeto "location" de JavaScript existe un método "replace", que tal vez podría servir para algo, puesto que sirve para reemplazar la URL actual "en el historial". Puede encontrarse más información en Internet. Sin embargo, se trata de una solución que pasa por usar Javascript y por el cliente. No sé hasta qué punto podría fiarse uno de algo así, pero, en fin, tal vez pueda ayudar algo.