Symfony security, sessions not cleared when logging out

I’m not sure if this will be covered in 1.1 (maybe someone can shed some light on it?) but currently when you logout using sfGuardAuth standard functionality, the session is not cleared/destroyed.

This only came to light recently, when I was scratching my head over why a parameter I had set was still available in the $sf_params array even after logging out, and logging back in again as a different user. This threw up an interesting security issue, because I started to wonder if I’d set any admin specific parameters elsewhere which could be reused by another user on the same machine.

The fix is fairly straightforward, but can only be run when not in test mode, because sfBrowser does not like the session to be destroyed! Maybe this is why it has never been written into the core functionality?

In apps/yourapp/modules/sfGuardAuth/actions/actions.class.php

 public function executeSignout()
     if (sfConfig::get('sf_environment') != 'test')

Adding the parent::executeSignout() line means that you can let the sfGuard plugin do the remainder of the work for you, so rather than overriding the function, you are just adding a bit to the start of it.

12 Comments so far

  1. Jacques Philip on August 4th, 2008

    This is good as long as there are no other values unrelated to sfGuardAuth in the session that you may need later.

  2. Russ on August 5th, 2008

    That’s true, I can imagine there are some cases where you’d want some session values to be remembered even after the user logs out – but then I guess it’s easy enough to reload the required data into the new session, or even just use some additional cookies.

  3. […] Symfony security, sessions not cleared when logging out […]

  4. […] symfony 1.1 has a signout bug, where sessions are not entirely cleared. Thanks to this blog post, I was able to hack something […]

  5. Thomas Boerger on November 26th, 2008

    You never got to manipuilate the session directly.

    You’ve got to add session vars with $this->getUser()->setAttribute(‘varname’, ‘varvalue’, ‘yourNamespaceForVars’);

    So if you are logging out you got to remove the namespace only and everything is fine.


    Kind regards,
    Thomas Boerger

  6. Thomas Boerger on November 26th, 2008

    And if you really want to clear everything that is on session write something like the following to your action:


    This call clears everything you have set on $this->getUser()->setParameter(‘foo’, ‘bar’)

  7. zairo on November 26th, 2008

    hi. I try all the suggestions but to no avail. Please help me.


    public function executeSignout()


    $this->getUser()->getAttributeHolder()->remove(‘referer’); $this->getUser()->getParameterHolder()->removeNamespace(‘referer’);

  8. Russ on November 26th, 2008

    Thomas: From a PHP security perspective, it is better not to just rely on clearing the Symfony attributes – totally regenerating the session is the safest way to go.

    Zairo: You should not be editing the plugin, if you need to override some of the functionality you should override the class in your own workspace.

    You should check that the file that you are editing is actually the one that Symfony is loading – put die(“hello world”); in there or something and click logout, just to see if you are actually having any effect at all.

  9. Bart on January 22nd, 2009

    Just a reminder that session values in Symfony can be stored in both a parameter holder and an attribute holder.

    So, while regenerating the session is the safest way to go, if you have to keep the session but need to remove any Symfony values be certain to clear them both.


    Thanks for the blog clearing this up!

  10. zairo on February 12th, 2009

    Mr Bart, your idea rock! Thank a lot. Now my session is totally clear after logout. 🙂

  11. Richard on February 3rd, 2010

    When I clicked on logout and if I go “Back” with Browser Back button, then inside page is coming again. Is there any way to stop showing inside page? once user clicked on logout.

  12. GermanK on February 5th, 2012

    I still had to do this hack on Symfony 1.4 sfGuardDoctrinePlugin. When I reused the same session id cookie, I could still see the session plain open.

Leave a reply