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.
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).
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 :/
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.
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.
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.
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.
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).