Montagne, Informatique & Pensées...

Laravel : Can't authenticate because sessions do not persist

publié le 12/06/2015

Today was a useless day !!! I spent 3 hours looking for an error that should have generated a HUGE error had I been doing good old PHP.

Don't misunderstand me, I do love the PHP I use for my applications, Laravel is just perfect as an Angular JS back end, Eloquent is simply the best ORM ever and I usually have no problem. That said, let's get down to today's problem.

My wife's planning manager was broken, she could not login in any more (nor could I By The Way). I started searching for the source of the error. After much googling I could not find anything that explained my problem. Most strange, the application was working on my computer but not on the production server.

After some debugging, I found out that sessions seemed not to persist. All I had to do was to find why. Digging deeper and deeper inside Laravel, I understood how the file session manager works. Apparently some guy came up with the idea that PHP Session were crap... I never had problems with them but I do not doubt that anything inside PHP could be made in a better way. This guy decided that this system should be replaced by a custom session manager storing files on the server (in the app/storage directory). But this still required to store the session id in a cookie (just like PHP does with sessions).

In order to do this, headers have to be sent... And any content is sent before the header : THERE SHOULD F...ING BE AN ERROR because you have requested the system to do something it cannot do. At this point comes the framework that caused my most numerous and lengthy nervous breakdowns : Symfony. Laravel uses parts of Symfony and in this case, It uses the HTTPFoundation classes. Here is the code that causes the problem :

public function sendHeaders()     {
      // headers have already been sent by the developer
      if (headers_sent()) {
            return $this;
Of course it may be logical to say that if the developer has chosen to send himself the headers, this method should not be called. But the fact that the headers have already been sent does not mean that it was the choice of the developer... It may have been an error (just like it was in my case) or he may have wanted to have sent a single header before the standard ones... In fact what bothers me the most, here, is the fact that something that should have at least generated a warning or a log is ignored silently !

It shows clearly that any warning on something that seems unimportant should really be passed to the developer (in dev environment at least). This principle is used by Laravel in all its specific code, it shows ugly error screen for warning or notice that would in production not even be noted forcing the developer to produce clean code.

The only solution I have if you want to be spared the 3 hour search and headache is to put an error_log before the return $this, just to show in the logs that this situation may be logical but may also be a big problem.

laravel symfony session authentication

Pourquoi un blog ?

Il me fallait bien entrer dans la modernité, après tout, un développeur sans blog, c'est comme un trailer sans pipette ça fait pas sérieux.

Je ne suis pas sûr que ce blog fera sérieux mais, si lecteur il y a, ce sera à eux d'en décider.

Powered by Jalmot