Se ingresa a un proyecto_1, se trabaja, se cierra la sesion con la X del lado del nombre del usuario, regresando a la interfaz del login del proyecto
Cuando se loguea sobre el mismo proyecto con otro usuario, igual ingresa sin validar y mantiene la sesion del proyecto con el usuario anterior.
Lo mismo sucede si en el url se cambia de proyecto ingresa con el primer usuario si tiene permisos para el otro proyecto, si no lo tiene muestra
No es posible cargar el usuario ‘10266377’. El mismo no posee un grupo de acceso definido para el proyecto_2, ; es decir no cambia a la interfaz del logue para el nuevo proyecto.
Esto no habia sucedido antes del cambio de version, por lo que concluimos un BUG
La unica forma de cambiar de usuario y proyecto correctamente es cerrando el navegador e ingresando con el usuario nuevo.
Lo cual es un problema porque para acelerar procesos en las salas no se cierra el navegador, y sobre un mismo pc se mantiene el primer usuario.
te hago una consulta, tienen hecha alguna extension para el manejo de la sesion?.. algun cambio que hayan efectuado al tipo de pagina?.
Te pido que pruebes lo siguiente para eliminar una posibilidad, una vez logueado al proyecto, edita la url y agrega lo siguiente al final ‘&fs=1’, dime si persiste el problema.
el problema persiste, ingresa con logueo, pero no valida y sigue en el mismo proyecto con el mismo usuario anterior
Cuando dices edita el URL, te refieres en el browser donde se escribe la url ?
Por favor le das alguna prioridad, estan ingresando notas y estamos en un grave problema.
estuvimos mirando con seba el sistema y notamos un par de cosas que creemos estan generando el problema, te pido que revises la configuracion de php ya que pareciera ser la fuente del inconveniente.
Las siguientes clausulas deberian estar de esta forma:
session.auto_start = 0;
Si se activa esta clausula, php envia apenas se hace el pedido de pagina una cookie con el nro de sesion activa, por su lado toba modifica el session name para utilizarlo de ahi en mas como cookie propia, el problema es que esto viene despues y por tanto la sesion autogenerada por PHP guarda efectivamente los datos de autenticacion, cuando te deslogueas toba envia una nueva cookie propia con el nuevo id pero el browser al pedir la pagina presenta ambas y como la sesion arranca automaticamente se toma la cookie de PHP con la informacion de autenticacion guardada, por eso el error que se te presenta.
Acabamos de subir un fix a la rama 1.4 para evitar este problema… pero eso simplemente lo que hace es detener la ejecucion, para solucionarlo hay que modificar el valor de configuracion de PHP.
session.use_trans_sid = 0;
Esta clausula debe estar desactivada tambien para evitar que el id de sesion viaje por URL, si te fijas una vez deslogueado en el link que aparece debajo de la pantalla de login se agrega dicha informacion, ademas aparece un campo hidden con la misma informacion tambien, esto puede contribuir a la realizacion de un ataque session fixation de manera mucho mas sencilla.
Recuerda actualizar la rama 1.4 y realizar estos cambios en la configuracion de PHP.
La solucion fue buena, pero el problema es que otras aplicaciones NO desarrolladas en Toba, necesitan almacenar las sesiones, por lo tanto se creo un conflicto con modificar el php.ini en “session.use_trans_sid = 0”, y al volverlo a activar con la actualización de
Toba esta saliendo un error:
Ya existe una sesión abierta, probablemente tenga activado session.auto_start = 1 en el php.ini
y si volvemos al toba anterior, volvemos al problema inicialmente planteado
Preventivamente se aplica en el archivo nucleo/lib/toba_session.php la siguiente funcion
function conf__final()
{
session_destroy();
}
El resultado aparentemente se soluciona, el problema es que la primera vez no toma los datos del logueo y la segunda vez si