“You are not permitted to use that link to directly access that page” Error when Trying to Edit a Joomla Article

An important client of ours emailed us yesterday and told us that they were having the following problem: whenever they edit an article, save it (or close it), and then try to re-open it, they are redirected back to the Articles Manager page (instead of being redirected to the edit page of the article). They told us that the issue was only happening on Google Chrome.

So we tested the website, and we were able to replicate the issue (only on Chrome), with one difference: the first time we tried to re-open any article, the Joomla CMS was throwing the following error:

You are not permitted to use that link to directly access that page (#[article-id])

We know, from experience, that that error is caused by session issues, so we checked everything that had to do with the session in the code…

First, we checked the file controller.php (which is located under the administrator/components/com_content/ folder) where the following code was responsible for throwing the “You are not permitted…” error:

if ($view == 'article' && $layout == 'edit' && !$this->checkEditId('com_content.edit.article', $id))
{
	// Somehow the person just went to the form - we don't allow that.
	$this->setError(JText::sprintf('JLIB_APPLICATION_ERROR_UNHELD_ID', $id));
	$this->setMessage($this->getError(), 'error');
	$this->setRedirect(JRoute::_('index.php?option=com_content&view=articles', false));

	return false;
}

After doing some quick debugging, we discovered that the problem with the above code was that the function checkEdit was returning false, for some unknown reason.

So we checked the function checkEdit which is located in the file legacy.php (which, in turn, is located in the folder libraries/legacy/controller), and we noticed that the following line...

$values = (array) $app->getUserState($context . '.id');

...was returning an empty array when it shouldn't. But why? And why is it the first time we try to edit the article it works, and the second time it doesn't?

And so we delved deeper and deeper and deeper into the session code while the wrinkles on our faces were multiplying by the minute (if you're a Joomla developer, you know that everything that has to do with sessions is a headache).

We then thought, we have an old copy of the same exact website residing on a development server. So we tested the old (development) website with a copy of the new database (e.g. we copied the database from the production website to the development website), and we didn't have the problem.

So it wasn't a database corruption causing this mess; it was a filesystem issue. We then compared all the changes in the PHP and the JavaScript files between the old website and the new website and we found no differences, except that the .htaccess file was present on the new website, but not on the old website which resides on the development sever.

So, in a moment of desperation, we copied the .htaccess from the production website to the development website, hoping that this will create the same issue on the development website, and it did! So the problem was with the .htaccess file.

Naturally, we started removing non-core lines from the .htaccess file one by one and then testing the website after removing each line, until we finally found the culprit, it was this line:

ExpiresDefault "now plus 1 hour"

The above line was instructing the browser to cache everything for one hour, including the actual PHP files, which was causing the session problems that we were seeing. What was weird is that it was only affecting Chrome.

So, how did we fix the problem?

Fixing the problem consisted of telling the browser not to cache PHP/HTML files, so, we added the following line to the .htaccess file (immediately after the aforementioned line):

ExpiresByType text/html "now"

(In case you're wondering, the above line instructs the browser to expire any PHP/HTML content immediately - in other words, the browser is instructed to always get that content from the server.)

We then tried opening an article, and then closing it, and then re-opening it, and it did re-open without redirecting back to the Article Manager page. Hooray! The problem was solved!

But why was the problem only occurring on Google Chrome?

We have no idea - and we didn't have the time to investigate why. It might be that either Chrome is very strict in listening to what the server tells it to do, or it might be that other browsers just don't listen that well (to the server), or it might be something else completely different. We don't know for sure.

If you're seeing the "You are not permitted to use that link to directly access that page", then check your .htaccess file, and make sure that you are not using any type of caching there. If you are, then we suggest you add the above line to your .htaccess file, it should work! If it doesn't, then please contact us. Our work is super quick, our fees are super competitive, and we know our Joomla!