[Php-avanzado] sesiones
Ariel Fernández
arielf05 en gmail.com
Lun Oct 20 08:20:41 ART 2014
1) exactamente.
2) tenés razón, hice eso y deshabilité lo de las cookies. Y que el usuario
verifique si está utilizando el login correcto. AHORA FUNCIONA.
3) cierto! esto te da una idea de lo confundido que ando con el tema :)
porque yo estaba pensando que sesiones y cookies iban de la mano, pero son
dos cosas diferentes. Las cookies se guardan en cliente y sesiones en
servidor (pero también con una cookie...) Lo del recolector de basura es de
php para el servidor, justamente para limpiar las cookies de sesión.
O sea que yo podría usar sesiones solamente y no necesariamente cookies
para mantener el logueo y parece que sí, porque ahora funciona con lo que
hice en 2)
4) ok, esto lo dejamos de lado.
5 y 6) ok, pero como es intranet, lo mantengo logueado hasta que cierre
navegador o luego de 8hs de inactividad, esto último simplemente por si no
usan una de las máquinas y queda encendida y logueada.
7) ah, o sea que con la configuración se session.lifetime ya alcanzaría
para "matar" la sesión automáticamente...
Saludos
El 17 de octubre de 2014, 20:06, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:
> Hola Ariel,
>
> hay varias cosas que me hacen ruido:
>
> 1) Si los usuarios usan el sistema permanentemente, será muy raro que se
> desconecte por inactividad, ya que a cada click tenés que estar
> actualizando el timestamp de la sesion, para que su vida se estire.
>
> 2) Si todo corre en una intranet, por qué simplemente no permitís el
> login múltiple? De esta forma si alguien se sienta en otra PC y se logea
> de nuevo como en el escenario que describís, ahora está dos veces
> logueado y no se "pierde" lo que el usuario que no se logueó está
> cargando.
>
> 3) las sesiones no se guardan en el navegador, sino en el servidor, así
> que cuando decís de "recolección de basura del navegador" estás pensando
> fuera del tarro ;-)
>
> 4) la autentificación de Apache si sigue y se seguirá usando. No es
> rústica, sino que solo soporta usuario y contraseña, así que en ese
> sentido es limitada. Sin embargo se puede ampliar con más datos de
> perfil, relacionando el usuario del .htaccess con un registro en una
> tabla. Tiene como ventaja y como desventaja que los usuarios nunca se
> desloguean mientras no cierres el navegador o aprietes un "salir" que
> implemente el logout.
>
> 5) es incompatible no desloguear nunca a nadie con la seguridad.
>
> 6) es incompatible tener control del usaurio logueado y no molestarlo de
> vez en cuando pidiéndole que se loguee!
>
> 7) el tiempo máximo de vida de la sesión te determina la duración
> máxima, independientemente de lo que software haga.
>
>
> Conciliá las cosas en tu implementación de AAA para este software y
> luego veamos los problemas técnicos...
>
> Saludos!!!
>
>
> El mié, 15-10-2014 a las 21:44 -0300, Ariel Fernández escribió:
> > Hola Leo !! no he buscado clases ahí, sólo ejemplos por la web, aunque
> > la base fue uno de los tuyos.
> >
> >
> > Mirá, en realidad, al principio me fallaba, luego funcionó bien y creí
> > que había sido por el recolector de basura del navegador, que lo había
> > configurado mal y me eliminaba los archivos de cookies. Pero resulta
> > que cuando instalé la aplicación en otra máquina, manteniendo todas
> > las configuraciones de apache y php, el login comenzó a fallar. Me
> > detecta que ya hay un usuario logueado (este chequeo lo hace
> > verificando el número de sesión en la base de datos, por eso, cuando
> > cierran el navegador sin hacer logout, el campo donde almaceno el id
> > de la sesión no se limpia y queda con el último usado y es como si
> > hubiese una sesión activa). Entonces, el sistema da la opción de
> > eliminar la sesión anterior, lo cual no es más que vaciar el campo id
> > de la base y hacer otro login. También se podría guardar la IP por
> > ejemplo, o ambas cosas...
> >
> >
> > Lo de los minutos, entiendo que no es bueno mucho tiempo, pero no se
> > trata de una aplicación online, sino que trabaja en red local, y sería
> > molesto tener que loguear a cada rato, además, es un sistema que lo
> > utilizan permanentemente por lo cual no tiene mucho tiempo de
> > inactividad. Para que te de una idea, el tiempo de la sesión lo
> > establecí en 8hs, luego de eso debería cerrarse la sesión...digo
> > debería, porque a mí me funcionaba, pero ya veremos....
> >
> >
> > Con .htaccess nunca busqué nada, me parecía que era algo de tipo
> > rústico...no sé....se utiliza eso?
> >
> >
> > Lo de "pérdida de datos" es más bien una advertencia que muestro al
> > usuario, porque inicialmente lo pensé por el lado de que si un usuario
> > inicia sesión en otra máquina, y no cerró la sesión en la máquina
> > anterior y alguien la estaba usando, y encima ese usuario la elimina
> > automáticamente (borrar el id de sesión de la base), entonces los
> > datos que estuvieran cargando ya no podrían guardarse porque el
> > sistema se cerrará solo, en el instante que chequee que la sesión fue
> > eliminada. No sé si fue claro ésto, puede ser medio confuso. Y tal
> > vez tenga que ver con el bolonqui que tengo ahora jeje
> >
> >
> > Trataré de ser más gráfico:
> > _Usuario A se logueó en máquina X y trabajó normalmente.
> > _Luego de un tiempo, Usuario A se va de la máquina X sin cerrar sesión
> > (porque se olvidó o lo que sea).
> > _Llega Usuario B y trabaja en máquina X con la sesión de Usuario A
> > (intencionalmente o no, sigue utilizando la sesión que estaba activa).
> > _Usuario A vuelve y ve máquina X ocupada e intenta loguearse en
> > máquina Z. (desconoce que el Usuario B está utilizando su sesión)
> > _En máquina Z, el sistema advierte a Usuario A que ya hay una sesión
> > iniciada en otra máquina (recordá Leo que está activa la sesión de
> > máquina X y en uso) y entonces le da la opción de eliminarla
> > automáticamente pero advirtiendo de la posible "pérdida de datos" si
> > es que la están utilizando.
> > _Usuario A decide eliminar esa sesión (de máquina X) para poder
> > loguearse ahora en máquina Z y poder continuar su trabajo.
> > _Usuario B, que estaba cargando datos en máquina X con la sesión de
> > Usuario A, cuando va a guardar esos datos, el sistema le advierte que
> > alguien ha eliminado la sesión y no se pueden guardar los datos. Ahí
> > Leo, es donde se "pierden" los datos....no pueden guardarse en
> > realidad, porque sólo permito una sola sesión por usuario.
> >
> >
> > Los datos que no se puedan guardar, no es nada grave, creo que es sólo
> > una molestia de tener que cargarlos otra vez, nada más. La idea es que
> > el sistema sea lo más amigable posible, pero bueno, si no respetan las
> > sesiones, creo que mucho no puedo hacer.
> >
> >
> > Ésto es lo que he implementado luego de investigar bastante sobre el
> > tema, pero no terminando de entender el tema de las cookies y
> > sesiones, y menos ahora que está fallando. Lo que vimos en clase fue
> > algo básico, lo entiendo, y me sirvió como base, como te decía al
> > principio, pero para implementar algo más completo, es ésto lo que me
> > salió.
> >
> > Si tenés tiempo, te paso el script de autenticación que escribí.
> >
> >
> > Bueno, gracias, saludos !
> >
> >
> >
> >
> >
> >
> >
> > El 15 de octubre de 2014, 17:10, Leonardo Tadei - Pegasus Tech Supply
> > <leonardot en pegasusnet.com.ar> escribió:
> > Hola Ariel,
> >
> > y en qué parte de todo esto estás trabado??
> >
> > Buscaste clases que se encarguen de AAA por ejemplo en
> > www.phpclasses.org ? No recuerdo haberme cruzado con ninguna
> > que te deje
> > logueado aunque cierres el navegador, pero sí que configuran
> > como
> > parámetro la cantidad de minutos que querés que dure la
> > sesión.
> >
> > Por otra parte, no sé si es buena idea que los login
> > duren mucho
> > después de demasiada inactividad... pero todo depende de qué
> > tan
> > importantes sean los datos a los que se acceden.
> >
> > Una autentificación tipo .htaccess por ejemplo no se
> > desloguea nunca
> > (salvo que cierres el navegador) y puede combinarse con un
> > perfil de
> > usuario más completo vía las variables de entorno
> > $_SERVER['PHP_AUTH_USER'] y $_SERVER['PHP_AUTH_PW']
> >
> > No debe ser sencillo encontrar lo que buscás, porque
> > de hecho todos
> > estamos buscando todo lo contrario: echar del sistema al
> > usuario para
> > prevenir robos de sesiones.
> >
> > Me llamó la atención lo de "evitar pérdida de datos"
> > al iniciar sesión
> > desde otro equipo. Qué estás guardando en la sesión que no
> > vale la pena
> > perder? No debería haber nada ahí que no sea estrictamente
> > volátil...
> >
> > Saludos!
> >
> >
> > El mié, 15-10-2014 a las 12:05 -0300, Ariel Fernández
> > escribió:
> > > Buenas, alguien implementó correctamente y con éxito algún
> > sistema de
> > > gestión de sesiones por cookies con verificación de
> > vencimiento,
> > > límite de un usuario por sesión y por máquina ?
> > >
> > >
> > > Porque realmente a mí se me ha complicado bastante y no
> > logro
> > > encontrar la forma de que funcione como tiene que ser.
> > >
> > >
> > > Mi código verifica el número de sesión que lo almaceno en la
> > base de
> > > datos al iniciar una sesión, y si alguien intenta ingresar
> > con mismos
> > > datos desde otra máquina, será alertado y se le dará la
> > opción de
> > > finalizar la otra sesión, pero sólo si no la están
> > utilizando para
> > > evitar posible pérdida de datos. Quisiera permitir además,
> > que se
> > > recuerde la sesión durante todo el día o hasta que hagan
> > logout, por
> > > más que se haya cerrado el navegador. Y el tema es que no
> > logro volver
> > > a cargar la sesión y reutilizarla. Hay tantos parámetros de
> > php que
> > > intervienen (como session.cookie_lifetime,
> > session.use_cookies,
> > > session.gc_maxlifetime, session.gc_probability,
> > session.cache_limiter
> > > etc etc) que tal vez estoy ocasionando alguna contrariedad.
> > Y tampoco
> > > termino de comprender lo de la función session_id(), la cual
> > > supuestamente me permitiría reutilizar la cookie.
> > >
> > >
> > > En fin, si alguien ha logrado algo similar y me puede dar
> > una mano,
> > > una pista, orientarme un poco aunque sea... estaré
> > agradecido.
> > >
> > >
> > > Saludos
> > > Ariel
> >
> > > _______________________________________________
> > > Lista de correo: Php-avanzado
> > > Mensajes a la lista: Php-avanzado en pato2.fi.mdp.edu.ar
> > > Administración Web:
> > http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> > > Desubscripción:
> > php-avanzado-request en pato2.fi.mdp.edu.ar?subject=unsubscribe
> >
> > --
> > Leonardo Tadei
> > leonardot en pegasusnet.com.ar
> > Web: http://leonardo.tadei.com.ar
> > Firma pública:
> > http://www.pegasusnet.com.ar/LeonardoTadei-public.key
> >
> > _______________________________________________
> > Lista de correo: Php-avanzado
> > Mensajes a la lista: Php-avanzado en pato2.fi.mdp.edu.ar
> > Administración Web:
> > http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> > Desubscripción:
> > php-avanzado-request en pato2.fi.mdp.edu.ar?subject=unsubscribe
> >
> >
> > _______________________________________________
> > Lista de correo: Php-avanzado
> > Mensajes a la lista: Php-avanzado en pato2.fi.mdp.edu.ar
> > Administración Web:
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> > Desubscripción:
> php-avanzado-request en pato2.fi.mdp.edu.ar?subject=unsubscribe
>
> --
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> Web: http://leonardo.tadei.com.ar
> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
> _______________________________________________
> Lista de correo: Php-avanzado
> Mensajes a la lista: Php-avanzado en pato2.fi.mdp.edu.ar
> Administración Web:
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> Desubscripción:
> php-avanzado-request en pato2.fi.mdp.edu.ar?subject=unsubscribe
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20141020/e520f4c8/attachment-0001.html>
Más información sobre la lista de distribución Php-avanzado