Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
After 1.5 upgrade from 1.3, Auth login persistence seems to have disappeared
  • When I upgraded to 1.5 just now I get the following issues which previously worked.

    auth/login
    if ($auth->login(\Input::param('username'), \Input::param('password')))
    {
    \Response::redirect('admin');    //todo:make configurable
    }

    admin/index
    if( ! \Auth::check() AND \Uri::string() != 'auth/login')
    {
    \Response::redirect('auth/login');
    }


    \Auth::check() is coming back false after the redirect where as before it would still be true. I see that a lot has been done around sessions and some around redirect so I imagine I was relying on some data that was sticking around to make this work which should not have been in a session or something, but I'd love to hear if anyone can help me pinpoint where this issue might be coming from.
  • Just FYI, I tested with 1.4 also, and 1.4 performs the same as 1.3 (meaning my login still functions properly)
  • I can't reproduce that (and I use this technique in each of my applications).

    The only thing that has changed is the contents of the session cookie. Instead of sending control data back and forth, validation now happens server side. This means that all outstanding sessions will no longer be valid, so logged-in users will have to login again (only once).

    What session storage do you use?
  • I have the same issue when migrating from 1.4 to 1.5.1. I use 'cookie' for session driver and Auth::check() allways return false. I don't understand why :/
  • I'll see if I can setup a test environment today. Can you create an issue for this at http://github.com/fuel/core/issues so it stays on the radar?
  • Okay. Just to add more informations, I just tried to change the session driver from "cookie" to "file" and everything works. But I don't want to use this method.
  • The issue is known, and only related to cookie sessions. I haven't had time to fix it, but will look at it later today.
  • HarroHarro
    Accepted Answer
    I've just pushed the fix.

    If you use a repo clone, just pull the updates for fuel/core in. If you have installed it from the zip, download the zip again, and replace the fuel/core folder.
  • Okay, i'll try the fix on my project later today. Thanks a lot for your reactivity.
  • I pulled the change from 1.5/master and saw your update. It causes my site to throw an internal server error when I use the 1.5/master core. My auth, orm, etc... packages are probably not updated to 1.5/master though so I'll try those out later tonight or tomorrow if I can.  Just out of curiosity, is it typical for you guys to update a master branch like this? I'm wondering how frequently I should pull updates to get bug fixes like this.
  • I updated the concerned file 'core/classes/session/driver.php' and everything is working fine know.
  • Thanks for the feedback.
  • Worked for me too. I was missing the new log package.
  • For some reason the repo disappeared from Github, so it could not be installed if you use the oil method or cloned the repo. This problem was fixed a few hours after release of 1.5.
  • Nevermind about this. I'm not sure exactly what the problem was, but I didn't have the same crypt.php config on each server so I fixed that and restarted apache on all servers. Perhaps it was the cookie encryption causing an issue. It is working now.

    ------

    I'm not sure if this is related, but I'm pretty sure it is. So your fix worked locally, but when I uploaded to our production environment (load balancer and 3 web servers) it seems to work inconsistently which is typically a multi server issue. I've checked a million times to make sure all servers have exact same code and such. Is there anything here that would result in cross server requests denying or not being able to read the cookies created by another server possibly? I have not run into this problem before the upgrade to 1.5.
  • Not that I'm aware of.

    For cookie based sessions, nothing has changed. All session data is still in the cookie, nothing is stored on the server, data is send back and forth as usual.

    For the other session types, the control data that used to be in the cookie (like IP, UA and other control information) is now stored server side, and the session cookie only contains the session id. Smaller cookie size, faster page load, encryption now optional.

    For the rest, nothing has changed to the way the session works.

    What is the definition of "inconsistently"? Loosing sessions? New sessions or existing sessions (from before 1.5)?
  • I think it was more of a configuration on my end. I had encryption enabled on cookies, so I'm guessing that uses the Crypt.php config to encrypt/decrypt. In addition to the crypt.php not existing or being different across all 3 servers I also did not have proper apache config files updated on all servers. So a combo of those two things at once fixed my problem. 
  • Your guess is correct. So if you have multiple frontends using the same session store, the crypt configuration must be identical. If you use Auth for authentication, the same is true for the auth config file (which contains the salt used to hash the passwords and the login hash).

Howdy, Stranger!

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

In this Discussion