2
votes

I'm experiencing a problem with symfony's session values handling.

Basically, the problem is this, I have a action filter activated that takes the values of the module and action executed and stores them in the session superglobal.

This is my filter's code:

<------BEGIN CODE---------------->

class getPrevModuleActionFilter extends sfFilter 
{ 
  public function execute ($filterChain) 
  { 
    //---------------Code to execute *BEFORE THE ACTION* execution---------------       
    if ($this->isFirstCall()) # Execute this filter only once
    {
      // Filters don't have direct access to request & user objects => Use context object to get them
      $request = $this->getContext()->getRequest();
      $user    = $this->getContext()->getUser();

      if($request->getParameter('action') !== "setCulture")
      {        
        $_SESSION['prev_module'] = "M=".$request->getParameter('module');
        $_SESSION['prev_action'] = "A=".$request->getParameter('action');
      }
    }
    //---------------Execute next filter in the chain--------------- 
    $filterChain->execute(); 

    //---------------Code to execute *AFTER THE ACTION* execution, before the rendering---------------
    //(...)

  }
}

<------END CODE---------------->

The weird thing is that if I do a print_r on the front web controller at the very last minute I see that:

  1. When an action that's not 'setCulture' all goes well (ie, the session gets previous module and action as it should)

  2. When action 'setCulture' gets executed: Symfony stores following values in session:

    Array ( 
        [prev_module] => M= 
        [prev_action] => A=    
        (etc)
    )
    

    ie, it looses the values of session for those 2 entries.

I tried using different namespaces, I tried using symfony's setAttribute from sfUser to handle session values. At the end I tried the raw session handling of PHP. Apparently it seems that the shutdown methods of the factories related to user and storage of session values mess up the session values!

I need your help, please.

SPECS:

  • Symfony version: 1.4.6
  • PHP: 5.3
  • I have Symfony's cache disabled
  • I'm running the code with the frontend_dev.php controller
1
Not sure I understand you correctly, but where you set prev_module, and prev_action if not setCulture is executed? - Tamás Pap
Hi Tamas :) Actually, the first action performed is not setCulture (it is home/index), so I'm pretty sure prev_mudule and prev_action get their respective values. Then I request the setCulture action and nothing gets executed....but the values from SESSION get lost! Any ideas? (thank you) - Rui Carvalho
I am pretty sure right now from my tests, that symfony messes up the SESSION superglobal if this array is accessed in the filters area. If accessed in actions, the exact same code runs smoothly with no lost in SESSION values. Weird! I tried almost everything, even looked up in sfSessionStorage.class.php to find where does it looses values from SESSION. One other thing, when that code runs in filters, I checked the session for the php script for symfony in the server and those variables loose their value, but are actually in session! hmmmm....I'm lost! - Rui Carvalho
I must add that the problem occurs not only with SESSION but also with COOKIES!!! Weird behaviour from using COOKIES in filters too.... - Rui Carvalho

1 Answers

0
votes

Well, I guess Symfony messes up SESSION and COOKIES when used in filters.

I ended up creating my own filter mechanism that performs actions for an entire app.

So, to clarify, my choice was:

  1. create a class autoloaded in root lib folder, that has a static method called 'fe_app_init'
  2. add a preExecute method to the actions of each module in FE app that uses fe_app_init from that class

Now the fe_app_init() handles the values in SESSION rightfully.

It's a shame that Symfony 1.4 has a tool such as filters but then messes up SESSION and COOKIES handling in those.