Yet Another Login Loop in Joomla’s Backend

Login loops are probably the most complex problems to fix on a Joomla website. Here’s the scenario: you go to the login page of the backend of your Joomla website, you enter your username and password, you click on the blue Log In button, but, to your surprise, you are redirected back to the login page with no error.

The thing is, we have encountered this problem many times before, and still, each time a client tells us that he has this issue on their website, we swallow about 8-10 aspirins, and we brace ourselves for a very, very long night… Unfortunately, yesterday (a Sunday), we were unlucky enough to work on this issue…

Yesterday started as very beautiful day, very sunny and with a very blue sky (which is not very common in Montreal), but it got cloudy pretty fast when a new client contacted us with the most terrible news: he wasn’t able to login to the backend of his Joomla website, and every time he tries to login he is redirected back to the homepage.

The reason why the news were that terrible is because we have yet to see two of these login loop problems caused by the same root issue. Each of these login problems is unique, as well as its solution. Still, were started the work with a healthy amount of optimism. But, as we later learned, optimism is a fickle friend, who jumps a sinking ship at the nearest opportunity!

We started the work by trying to find whether the cause of the problem is one that we have encountered before:

• Is the tmp physical path (the $tmp_path variable in the configuration.php file) correct and writable by the web server?

• Is the log physical path (the $log_path variable in the configuration.php file) correct and writable by the web server?

• Is the cookie domain (the $cookie_domain variable in the configuration.php file) empty?

• Is the plg_user_joomla plugin enabled? Is the plg_authentication_joomla plugin enabled? (Note that we used phpMyAdmin to check for the value of these two plugins in the #__extensions table).

• Is the session handler (the $session_handler variable in the configuration.php file) set to database?

• Are all types of cache disabled?

As you may have probably expected, all the above were OK – if they were not OK, then what is the point of this post? So we decided to take a more aggressive approach to solve the problem…

We started our aggressive approach by overwriting the Joomla website with a fresh copy of the same version of Joomla using our super quick famous technique for cleaning up Joomla websites, but that didn’t work!

So the next step in our aggressive approach was to check the controller.php file (located under the administrator/components/com_login folder) which is the entry file responsible for logging in the user (there are other, deeper files that effectively handle the login, but this is the entry file). A thorough debugging of the file revealed that the problem lied in this line:

JSession::checkToken('request') or jexit(JText::_('JINVALID_TOKEN'));

If you’re a close follower of our blog, then you may remember that we have published several articles on Joomla’s invalid token error. In fact, in one of our blogs, we concisely explained how to get rid of the invalid token error once and for good. But, we didn’t want to do apply this fix for that client because 1) he was using the latest version of Joomla, and 2) there shouldn’t be a reason for him to see that error on his website in the first place, and 3) this is a last resort solution.

So, obviously, the issue is caused by a problem with the session storage, but we have already checked everything – literally everything having to do with the session, so why do we have a problem with session storage? At this point, we were only able to think of one culprit: a Joomla update that left some reminiscent files from a previous version… So we compared the files of the Joomla website with those of a fresh Joomla website (having the same version), and we noticed that there were some extra files/folders in our client’s websites (reminiscent files from a previous Joomla version). We deleted the extra files and folders and we tested this problem again, but still, it didn’t work.

In order to break the series of unfortunate events (yes, we are alluding to the movie here), we called our moms so that they can give us much needed morale, and they did. We then relaxed for a bit and then started attacking the problem again! We thought, hey, there is this one file that we haven’t checked yet and that we credit with a not-so-small percentage of all the evil in the world (let alone Joomla): it is the .htaccess file. So, we opened the .htaccess file, and, in its very beginning, we saw the following 2 lines:

Header set Set-Cookie "VC-NoCache=1; max-age=900; path=/"
Header set VC-NoCache "1"

Huh? What is that, we thought? Is that something that has to do with caching? Let’s just comment out these 2 lines and see if that takes care of the problem, and it did! We were able to login without being affected by the vicious and ruthless login loop. We were happy but we were tired – it was a frustrating and a scary experience!

If you, our dear reader, are on the brink of deleting your whole Joomla website (and business) because of this error, then please check our previous posts about this issue (which are linked to in the beginning of this article), and also make sure that you don’t have something in your .htaccess file causing this problem. If you are not able to solve this problem, then just contact us and we’ll take care of it. But, before doing that, please make sure you check our fees and please don’t forget to send us a blindfold and a cigarette – we may need them!