Esta información la extraje del manual de php
http://us2.php.net/session
Cita:
Hay dos formas de propagar un "session id": - Cookies
- Parámetro en la URL
El módulo de sesiones admite ambas formas. Las Cookies son la mejor opción, pero como no son fiables (los clientes no están obligados a aceptarlas), no podemos confiar en ellas. El segundo método incrusta el "session id" directamente en las URLs.
PHP es capaz de hacerlo de forma transparente al usuario cuando se compila con --enable-trans-sid. Si activa esta opción, las URIs relativas serán modificadas de forma que contengan el session id automáticamente. Alternativamente, puede usar la constante SID que está definida, si el cliente no envía la cookie adecuada. El SID puede tener la forma de nombre_de_sesion=session_id o ser una cadena vacía.
|
Otra forma de implmentar
session tracking es mediante
URL Rewriting. (Aunque hay quienes confunden url rewriting con enviar el id de sesión mediante GET, no es este el caso.) Esta técnica permite incorporar el id de session
dentro el path (no del query como hace GET).
Por ejemplo, sea el número de sesión el 12333444555 y el recurso al que invocamos es
http://www.example.com/test1.php.
Colocar en el query sería algo así como:
http://www.example.com/test1.php?ID_SESSION=12333444555
Colocar en el path sería:
http://www.example.com/12333444555/test1.php
(En el Apache, revisen el mod_rewrite para implementar esto.)
Los cookies son utilizados para almacenar información en el disco duro del cliente. Qué se puede colocar ahí? tenemos 4k por cookie de "cosas".
Eso depende de la iniciativa del desarrollador acerca de lo que se debe colocar ahí. Se puede colocar un identificador del usuario para ir mejorando sus preferencias en cuanto a navegación por un sitio. Por ejemplo, en un periódico, podemos registrar el tipo de noticias que ha navegado el cliente y luego dar una clasificación que permita al software, la siguiente vez que el usuario visite el sitio, las noticias de su elección.
Se puede, se puede, se pueden hacer muchas cosas. Pero no estar informados acerca de lo que existe es cometer un error severo que puede costar al contratante más que al usuario.
Por ejemplo, alguna vez entré a la Agencia Federal para el Manejo de Emergencias de los Estados Unidos y en la parte de Privacidad del Usuario y Aviso de Seguridad mienten descaradamente cuando dicen:
Cita:
|
Empezado por http://www.fema.gov/spanish/help/privacy_spa.shtm
- Éste es el estado de la tecnología en Web. En la actualidad no existen aplicaciones que no usen cookies para esta función de pedidos múltiples.
Puede tener la absoluta seguridad de que el uso de la tecnología de cookies por parte de FEMA NO constituye un intento encubierto para recopilar o analizar información sobre usuarios de Internet. |
Hay caramba! No creo que los técnicos de FEMA nos mientan descaradamente! Podrá ser que una institución seria como el FEMA se haya equivocado? Tan grande ! Tan estatal ! Tan técnica ! Se habrá equivocado? Les habrán hackeado la página para poner mentiras y hacerles quedar mal?
Aquí es donde las cosas se ponen viscozas. Cuando afirman que
ES EL ESTADO DE LA TECNOLOGíA EN WEB cuando deberían decir (por verguenza deportiva al menos)
ES EL ESTADO DE LA TECNOLOGíA EN WEB que conocemos.
Mensajes como éste han hecho que mucha gente piense que no existe nada más allá de los cookies. Y los que no los tienen o no los quieren: $@#!$. Así que, hay que usar nomás cookies sin ver lo que son o lo que hacen?.
Mucha de la tecnología de cookies está sustentada en mentiras (como la del FEMA) o en verdades a medias.
Hay algunas cosas buenas que hay que decir de los cookies: son seguros; son soportados por la mayoría de los browsers; no contagian virus ni los transportan(?); no son intrusivos y tampoco ocupan mucho espacio.
Entonces, quitando el tema de sesiones y seguridad, en qué se pueden utilizar cookies que:
- No viole la privacidad del usuario
- Si el usuario no quiere usarlos, no sea excluido
Hay todavía espacio para los cookies después de responder esa pregunta. Por ejemplo, en amazon.com, cuando un usuario visita una de sus páginas, son registradas sus preferencias, de tal manera que la siguiente vez que se conecta le muestran las novedades que, corresponden a sus preferencias. Pero, utilizar cookies para pedir la tarjeta de crédito del usuario? NUNCA!!! para eso existen el
https y el
uri rewrite. Finalmente, si el cliente no recibe cookies, no importa, no se perderá la conexión con un usuario por ello. Será tratado como un usuario nuevo y se le mostrarán las preferencias por defecto.
Cita:
|
Empezado por dec
No vale decir "no uses cookies en modo alguno",
|
No uses cookies en modo alguno... para temas de seguridad. Para los demás temas, valdrá la pena esforzarse en usarlas?
Saludos