Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Sessions and redirect causing session to lose some values


  • I have an odd situation. consider the following scenario:



    1. form on page posts to another domain
    2. that domain processes data, and posts back to controller A
    3. controller A processes returned data, and sets flash session vars
    4. controller A redirects to controller B
    5. session values set in controller A are lost.


    Now, I have noticed that if I eliminate step 4; the session values
    are not lost. It is only happening after calling Response::redirect().



    Following is the relevant code in controller A's post handler (in
    this case, $vars is set to Input::post(); and the renew() method does a
    soap call to another API, and returns response data.):



    $success_object = $this->renew( $vars );
    $persist_through_redirect = array(
    'accountId' => $success_object->account->accountId,
    'expireDate' => $success_object->account->expireDate,
    'createDate' => $success_object->account->createDate,
    'due_amount' => $success_object->account->lastPaymentAmt,
    'offer_name' => $offer_name,
    'member_name' => $vars['first_name'] . ' ' . $vars['last_name']
    );
    return $this->redirect('success/', $persist_through_redirect);


    And this is the code behind method redirect():



    private function redirect($redirect_endpoint, $redirect_values = null) { 
    Session::set_flash('flash_redirect', $redirect_values);
    Response::redirect($redirect_endpoint);
    }


    Finally, here is the code in controller B that accesses the session data:



    $information = Session::get_flash('flash_redirect');
    if(isset($information)) {
    View::set_global('membership', $information);
    }
    // set the locale based on fuel's setting
    View::set_global('locale', str_replace( '_', '-', Fuel::$locale ));
    return View::forge('successes/success_card');


    It gets weirder though. Not all session data is lost. Any session data I had set in the before() method is staying put. It is also worth mentioning that whether I use set() or set_flash(), I have the same result



    I'm very stumped on this one. Any ideas why my session data is lost? I don't think it has anything to do with posting to the other domain (since there are conditions where the redirect will not happen, and in those cases the session vars are still there as well), but who knows? So far Fuel has been very kind to me, until this. :P

    EDIT: I also forgot to mention that SOME session vars are kept. There is one session value that gets set in the before() controller method; and that one seems to stick regardless of redirect or not.




  • Maybe you can use the "keep_flash" function to set/save the needed informations as long as you need it.

  • Flash data expires at the next request, used or not.

    Which means that when you redirect, you lose your flash data, unless you 'refresh' your flash data like Marcus suggests, or you disable flash auto-expiry in your session config by setting "flash_auto_expire" to false.

    Note that this means that if you set flash variables you never get, they will be stored until the session expires. This may have impact on the size of your session.
  • I have tried to convert my use of set_flash() to simply just set() to see if that was the core issue, but these variables are lost regardless of method used.
  • What Fuel version are you using? What are you using as session backend?

    And do you have the issue in every browser?
  • We are using 1.6; cookies type sessions. All browsers.

    I have more info on this though. I added a call to Session::write() just before the redirect. When I did this, I got an exception about the cookie being larger than 4kb. I suppose what is happening is that when I do a redirect, I do not get a chance to see this error, and the logs do not show it either.

    Now I am trying to figure out WHY it is greater than 4kb.

    EDIT: I looked through profiler output, and it appears at some point all of my post data is being pushed to the session. I can;t seem to find any code that would do this though. Just wondering now if there is any "magic" in fuel that pushes post data to the session automatically?

    EDIT 2: Ok it is confirmed, there was some code hidden in my controller that was pushing all of my POST vars to the session! For anyone else who is having an issue like this; try adding a Session::write() call before the redirect to see if there is any exception being thrown.

    Thanks for the help guys! Sometimes it helps just to lay the problem out :D
  • There is no magic in Fuel. At least not of the type that decides to do something on it's own.

    In general, using cookies for session is a bad idea. It requires encryption, which introduces CPU overhead, encrypted data is base64 encoded, so it takes up more space (and cookies don't have a lot as you have noticed), and with every request, all this data is send back and forth, making your application slower.

    I would not recommend cookie based sessions for anything, other than perhaps a very small and simple site where you just want to remember some preferences, and that doesn't have some kind of storage backend.

    If you're application is any more complex (and I think it is), switch to server side storage.
  • Ah, and a ps:

    If you make sure your logging is set so that you at least \Fuel::L_ERROR, you would have seen the exception error message in the log. Would have saved you a lot of searching...
  • Thank you for the tips. So far as the logging is concerned, I actually have it set to Fuel::L_ALL, yet still did not see it.
  • Weird.

    Just checked the 1.6 codebase, and the Error class does use logger() with L_ERROR to log both exceptions and PHP errors. Unless the Exception object has it's own handler, but that is not the case here.

    With L_ALL, every request should be logged, are these entries written to the log file?
  • All I see in the log file are requests really.

    I think you are on the money with the custom handler though; we do use a custom handler. I didn't think that was in a try block, but come to think of it, that code does run in a try block; just a bit indirectly.


    P.S. Off topic, but just wanted to say I really love the framework so far!

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion