orden de busqueda de session id

e-miliox · #1 (**permalink**) 26/05/2003, 15:48

en mi aplicaciones de php, estoyhaciendo el manejo de las sessiones de manera independiente de las funciones del php, eso es, guardando las sessiones en la db, y generando el sid yo mismo y traspasando las sid a travez de la url, por post y cookies.

mi pregunta es, si al mandar la sid por cualquier metodo , cual seria a su criterio el orden en que revisaria estos para recuperar la sid

por ejemplo yo para hacer esto, reviso primero
1.- cookie
2.- get
3.- post

no se si se entendio bien :)
gracias de antemano, saludos

Cluster · #2 (**permalink**) 26/05/2003, 17:26

¿Orden?

El caso es que leas todos los métodos .. a no ser que configures tu aplicación para que trabaje con Cookies o propagación por el URL (sea POST o GET) ... (uno de ambos métodos sólo ..)

Un saludo,

e-miliox · #3 (**permalink**) 26/05/2003, 18:22

okay, esto de las sessiones me ha llevado algun tiempo entenderlas bien. :)

yo estoy tratando de hacer una prioridad de cual seria mas logico leer primero, he visto que algunas aplicaciones manejan a su manera las sessiones del usuario. La idea es que si yo no se que metodo he elegido para propagar el id, debo revisar si la sid existe en algun lado para poder retomar o enviar al login respectivamente.

por ejemplo al enviar un formulario la pagina que recibe probablemente no sabra porque metodo vien, si por post o por get y debera revisar en ambos casos, pero CUAL reviso primero, el get y luego el post, o el post y luego el get?, lo mismo, si a eso le incluimos las cookies cual podria ser el orden?

estoy experimentando con esto, quizas este equivocado o me convenga solo decidirme por un metodo solo, usar cookies, o propagar por get/post,

la estructura de login y comprobacion de la sesion actualmente la tengo solo mirando el url (GET) y estaba pensando que quizas seria conveniente o, digamos, mas completo hacerlo tambien con una cookie, entonces primero miraria si existe la cookie, si existe tratamos de conseguir el sid, y luego, revisamos la url y si sid tambiene existe ahi reemplazamos el valor asignado anteriormente, que corresponde al valor que habia en la cookie, y lo reemplazamos por el que esta en la url...luego revisamos en la base de datos si ese valor de sid existe en mi tabla de sessiones y etc etc...

esa seria la idea, acepto correcciones y criticas :) (constructivas claro)

saludos!

Cluster · #4 (**permalink**) 26/05/2003, 20:21

Pues como lo tenías es lo ideal:

1.- Cookie

2.- GET
3.- POST

Si usas propagación del SID en una cookie .. fuerzas a cada cliente que ejecute tu aplicación (navegador) a que acepte cookies. Cosa que , si bien es lo mas seguro para que no se te "escape" un SID hacia un sitio externo a tu sitio .. ya tienes un "problema" si te tocas con un navegador que no quiere aceptar cookies.

No sé como estaras implementando tu própio sistema de sesiones (supongo que definiendo tu própio "handler" (o como se escriba ..). Pero, si dices que no conoces bien como funcionan las "sesiones" en general .. primero deberías conocer bien como se lo trabaja PHP y luego implementar tu sistema ...

Comentario:
A mi me parece excelente como trabaja PHP las sesiones (sobre todo desde PHP 4.3.0 donde se ha mejorado muchooo la seguridad de las mismas).

El hecho de que tu generes tu própio SID (nombre sesión + ID) bueno .. está bien pero el que genera PHP ya es bueno (un MD5() de 32 caracteres alfanuméricos ..).

Si te "asusta" tener tus sesiones compartidas en un servidor virtual (como suele pasar en un servicio de hosting) .. Puedes indicar que directorio guardará las sesiones (el "file") que crea PHP por defecto en un directorio bajo tu control.

El nombre de la sesión .. como ya sabes se puede cambiar del que toma por defecto del php.ini (PHPSESSID).

Tiempos de expiración "largos" también se pueden definir (eso sería una de las ventajas que a simple vista se vé si usas tu própio sistema de sesiones guardandolas en una BD) ..

En cuanto al rendimiento del sistema de sesiones en si .. habría que testearlo .. Pero creo que "machacar" a tu BD Msyql para usar sesiones .. creo q es una cagar demasiado alta.

En fin .. yo creo que una buena configuración y uso del las sesiones que aporta PHP (4.x) sería lo ideal para no andar "reinventando la rueda" ...

Por cierto .. se me olvidó .. No sé si te sonará o acordaras de las librerias PHP LIB (de PHP 3.x) .. ahí nació el sistema de sesiones que luego lo implementó nativamente PHP 4.x .. Parece que estás haciendo el mismo (o parecido) sistema .. ¿Es así?

Un saludo,

e-miliox · #5 (**permalink**) 26/05/2003, 23:01

esteee, bueno la verdad es que como estoy experimentando con esto me lance a hacer un mini sistemita yo mismo (pa entender un poco mas el asunto) y para tener un poco mas de control sobre lo que estaba haciendo.

la idea la saque de algunos sistemas ya hechos, por ejemplo el que trae el phpbb, los que manejan sus propios sistemas para administrar las sessiones.

sabia que phplib tenia su propio sistema tambien, pero lo que no sabia es que son los mismos que se manejan en PHP 4.x =D

asi que luego de esto, creo que hare lo mismo pero con las funciones de php.

lo que quiero lograr es hacer un sistema solo en el que se pueda entrar con clave y a la vez de utilizar las funcionesde session, respaldar con la db para guardar mas informacion y tal vez hacerlo un poco mas seguro. para eso alguna vez creo que hice unas modificaciones a otro sistema que hacia lo mismo pero que reemplazaba los handlers para sessiones por los suyos propios con la funcion session_set_save_handler()... o no es necesario?

gracias por la ayuda

Cluster · #6 (**permalink**) 26/05/2003, 23:28

Yo veo mas factible usar tus própios handlers via: session_set_save_handler() y fuciones afines .. que crear tu própio sistema de sesiones integro.

Yo a la sesión lo veo como lo que es .. un sitio "temporal" donde guardar unas variables .. y ese tiempo más bien corto. Los datos que guardo no suelen ser muchos, pero tampoco sé si hay limite mas que el própio físico del sistema de archivos del servidor para los datos de una sesión .. La seguridad me lo dá el hecho de que esos datos permanecen en el servidor y no viajan hacia el cliente (caso de las cookies) .. los llamo desde PHP (en el servidor) hacia la sesion (en el servidor) ...

Los motivos de "seguridad" ya te los he comentado .. Creo que una buena configuración (que eso parte de conocer bien como trabaja PHP el tema sesiones) y con algunos detalles como te comenté .. no deberías tener problemas usando las sesiones de PHP nativas, que para eso las implementaron .. para aliviar nuestro trabajo como programadores y no andar sobrecargando nuestros scripts y aplicaciones con funcionalidades que si las gestiona PHP en su "core" (cuerpo, kernell .. por decirlo así ..) siempre serán más óptimas en rendimiento que lo que podamos hacer con un "script" nuestro que tenga que "interpretarlo" PHP.

La mayoría de veces .. la desconfianza sobre algo es simplemente por el desconocimiento de eso mismo .. Eso hace que nos "rompamos" la cabeza buscando nuestra alternativa "mejor" (bajo nuestro punto de vista) .. que tal vez sea buena, pero igual miramos "para el lado" y vemos que ya lo está haciendo PHP por ejemplo de forma nativa.

Un saludo,