Ayer encontre un “bug” (por llamarlo de una manera) en el manejo de sesiones de Symfony 1.4 usando sfGuard, me dí cuenta que cuando inicias una session con el usuario A, guardas un dato en la session del usuario A, deslogeas al usuario A, logueas a un usuario B, en los datos de la session de B estan los datos guardados para el usuario A. Obviamente se pueden dar cuenta de los problemas que puede llegar a traer esto.
Para probar puse en fragmento de código que setea una variable de session con el timestamp, una vez seteada la variable nunca mas se cambia el valor. Se supone que si me logeo la variable se setea por primera vez, al deslogearme la variable debería eliminarse.
Aqui un par de screenshots the la barra de debug de symfony, la primera es antes de logear al user, aqui pueden ver que la session esta limpia.
la segunda es con el el usuario logeado mostrando el valor de session, la variable fue seteada.
y la última es con el usuario deslogeado nuevamente pero con el valor de session ahi.
Si vuelvo a entrar con ese usuario u otro usuario la variable nunca cambia el valor.
El problema sucede tanto si usas setAttribute del Objeto de usuario o si metes el valor directamente en $_SESSION.
Una solución rápida que encontré fue colgarme del evento de user auth change para ver si el usuario se esta deslogeando, en ese caso llamo a un session destroy para limpiar todos los valores de la session.
Como sería esto, bueno, primero, cree una clase para el método que quiero hookear, llamemosla swSessionReset y pongamosla en lib. La clase sería algo así
class swSessionReset {
static public function resetSession($event) {
if ($event['authenticated'] === false) {
session_destroy();
}
}
} |
Después tenemos que hookear el método de esta clase. Para eso vamos al ApplicationConfiguration y añadimos estas lineas al método configure.
class applicationNameConfiguration extends sfApplicationConfiguration {
public function configure() {
//Some Code ....
$dispatcher = ProjectConfiguration::getActive()->getEventDispatcher();
$dispatcher->connect('user.change_authentication',
array('swSessionReset', 'resetSession')
);
}
} |
Con esto, cada vez que el usuario se deslogue forzaremos la limpieza de todos los valores de session.
Después de ver esto @gerzenstl me hizo notar que Drupal al deslogear un usuario invoca al session_destroy, aca esta el código para que los desconfiados revisen
http://api.drupal.org/api/drupal/modules!user!user.pages.inc/function/user_logout/6
Conclusión, “ojo al parche torrente!”, tengan cuidado con esta consideración por que puede traerles graves problemas de seguridad. Prueben si a ustedes les pasa lo mismo, puede ser que el sitio en el que estoy trabajando actualmente tenga algo modificado que rompe esta funcionalidad (IMHO no creo), después me cuentan como les fue.
Esta es una pequeña guía de como encarar un proyecto nuevo con symfony 1.2 desde un sandbox, sobre un sistema Debian, con Apache 2, MySQL corriendo localmente y que utilizaremos como ORM Propel.
nte suele enviarme correos para que los ayude con sus desarrollos con Symfony, mirando mis readers de hoy me encontré con este sitio: