Logout. Login. Fixed. As Per the FAQ!

https://docs.joomla.org/Category:Version_3.4.7_FAQ

@PhilETaylor please also read #8731

And for my yesterday fresh made installation of joomla 3.4.6, today updated to 3.4.7, containing only the test content it now reliably occurs!

So only logging in and out as per the FAQ does NOT solve the issue!

One more Information: it is reproducible with Chrome 47, 48 and current IE 11, but NOT with Firefox 43.0.1.

And editing reliably works if instead clicking on the article title, you check the check box to the left of the article row and click on the edit button on top of the article list.

hmmm I can see this now.

Update to joomla 3.4.7
Go to manage/templates in the backend
Click on one of the templates.
Page refreshes...

Confirmed.

Although - as soon as I logout, and login again I can then edit templates

Update to joomla 3.4.7
Go to manage/templates in the backend
Click on one of the templates.
Page refreshes...
Logout/Kill session
login
Tempalte Manager
Click Template
Edit page shows fine!

@PhilETaylor Yes but try to edit twice in the same session!

I can constantly edit, save and close, edit another, save and close, edit another save and close...

@PhilETaylor which browser are you using?

@PhilETaylor and please edit the same article again and again. Do not change to another article.

The problem will not be related to browser. The only thing changed in Joomla was Sessions at the PHP level.

I can consistently edit tempaltes in Google Chrome, TorBrowser, Firefox and Safari on Mac.

Edit the same article again and again. Do not change to another article - see screencast:
http://screenshot.myjoomla.io/1k17402e1A2T

No problem found.

And here is my screencast:

https://drive.google.com/file/d/0BwoJi2e8W5N1aWRtOGpyVGFzM3c/view

which shows the issue.

I can not reproduce it on 3 completely different instances. It looks like a local problem on your Joomla! installation.

I've two fresh joomla installations as of yesterday, one with 3.4.5 and one with 3.4.6. The 3.4.6 installation was updated today to 3.4.7. So there is no version history or content history in there. All configuration options are default. No additional components, plugins, modules or whatever installed.

Logout and log back in and it should resolve the issue.

@oogloo No simply logout/login does NOT solve the issue. Please see my screencast:

https://drive.google.com/file/d/0BwoJi2e8W5N1aWRtOGpyVGFzM3c/view

Just to calm things here - please be aware that you have some of the Joomla team looking into this in private - please have some patience, The people in the know are debugging and investigating and will get back to you when they have something more to say - there is no point in posting every little thing they discuss here at this moment.

We cannot replicate your exact issue - however there has been some progress on identifying some kind of expired session issue.

This might or might not be connected with #8755 (comment)

OK. Thank you for investigating. Just wanted to be shure this one gets your attention.

I have a similar problem. I can't create new menu items or new modules. Additionally I now get a "You are not permitted to use that link to directly access that page (#2)." in the admin panel of one of my components when attempting to edit them.

@jacklogic13 if you logout and login again is everything fixed? PHP version? Cache timeout? Cache handler?

I've now cleared all history and logged back in and it does appear to be working now so thank you for that.

TL;DR Version

You just got very unlucky. There's a nasty combination of things that should happen in order to get in such situation.
Just logout and login again, everything will be fine after that

A more detailed explanation

Joomla! flushes the expired sessions randomly, to avoid too much pressure on the server. Sadly, if the session expires and it's not flushed, you're caught in the middle. We're working on it to fix this.

Thanks @tampe125 Looking forward to a fix for this issue.

Logout/login fals in a lot of situations. Moist reported (see forums) are "cannot login any longer in backend" despite logou/login +sessions as referred to by JM + the issue as mentioned by @tampe125 which we have seen also multiple times on the forums....

I wish simple logout and login would resolve this --> does for sure not!

I do agree with Phil that we cannot reproduce it (on our servers) but the forums are very clear so we do have an issue like it or not

Clear your cookies and try again.
Clear your database table #__session and try again
Post results here.

Phil we have done that on several support assists in different system environments and it does not resolve regretfully. Emptying session table and a complete browser cleans including change of browser does not resolve

So what are the specifics of when that doesn't work? PHP version? Mysql version? Unix Host? Windows Host? We need to start listing those details in one place instead of a million open issue tickets!

Until there is a link between those that dont work, and when people post more than "it doesnt work" then maybe we can get to the bottom of it

I know several top notch developers have taken responsibility for, and are giving up their christmas to look into and resolve this - but you need to play your part in providing accurate information.

It works in some instances, so the code works in some instances - its time to get to the specifics of WHEN it doesnt work with specific platform information.

Logout and log back in and it should resolve the issue.

It's working good now for me

A 3.4.8 Release Candidate Package (https://github.com/joomla/joomla-cms/releases/tag/3.4.8-rc) has been released for testing. Some of these issues are not reliable - so just give it a try and see if you come across any issues :)

seems to be fixed on the rc

@wilsonge The release J3.4.7 includes bunch of code here to prevent logout on update. In the subsequent bugfix release J3.4.8 we force logout.

Additionally, the logout only happens for the user who performs the update. Any other administrator still faces the above issues unless they logout and login again manually.

I sent a PR #8782 immediately after J3.4.7 and before release of J3.4.8, which is unnoticed so far. That proposes a fix for this.

Since the 3.4.8 still does not fix the problem, I request you to please look into that once.

I'm using Joomla 3.4.8 and I'm seeing issues that seem to follow this thread about having to refresh the browser after making an article update and pressing save from the backend admin area. You make the changes, hit save, screen reverts back to prior content. You refresh browser, you then see your recent updates.

Joomla 3.4.8
PHP 5.4.35
DB Version 5.5.46-cll
Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4

that sounds nothing like a Joomla issue - and more like a server/caching issue

We are having the same issue as stated at beginning of thread. Click on an article header, opens edit screen. Close out of article. Try to click on same article, get an error (You are not permitted to use that link to directly access that page #252). Try to click on same article again, no error but stays on the articles listing page. This issue only seems to happen with Chrome and Edge. Firefox had no problems. Safari no problems. No logout needed. No clear cache.

Here's a kicker. We updated to 3.4.8 prior to seeing this issue. Our site was very slow, so we went to optimize it using theses tips from this article: https://www.siteground.com/tutorials/joomla/joomla-speed.htm#cache
After implementing the .htaccess Optimization Rules, the error was discovered. Removed code from htaccess and the problem went away.

Site slowness seems to be more because of it being a shared server on GoDaddy and we hit our I/O limit.

PHP - Built On Linux p3plcpnl0750.prod.phx3.secureserver.net 2.6.32-531.29.2.lve1.3.11.10.el6.x86_64 #1 SMP Fri Jun 12 15:09:02 EDT 2015 x86_64
Database Version 5.5.45-cll-lve
Database Collation latin1_swedish_ci
PHP Version 5.4.43
Web Server Apache/2.4.12
WebServer to PHP Interface cgi-fcgi
Joomla! Version Joomla! 3.4.8 Stable [ Ember ] 24-December-2015 19:30 GMT
Joomla! Platform Version Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
User Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

@techmerlin and what happens if you logout and log back in again? It resolves the issue right?

All sites are slow on GoDaddy, its a slow webhost.

Please note your server is running PHP 5.4.43 and therefore you must start hassling your web host to upgrade to PHP 5.6.x

See: http://php.net/eol.php and http://php.net/supported-versions.php - We strongly advise you to hassle your host to upgrade your site to PHP 5.6 or later as its the ONLY SUPPORTED PHP VERSION and the only one to trust! (Except maybe PHP 7)

Also

Database Collation latin1_swedish_ci

is wrong. It should be utf8.

@PhilETaylor 'and what happens if you logout and log back in again? It resolves the issue right?'

Yes, but only for one use per article. It will go back to the original problem if article is clicked on again. I have left the optimization code off of the htaccess file for now because the site seems to be cruising along without it. With that code removed, everything seems to be running correctly.

Thanks @infograf768 ! I totally didn't see that collation. Made the change... unfortunately, it did not effect the problem (with the optimization code added)... but probably cleaned up other stuff, though.

Hello

here is an explanation of why this is happening:

• editing is 2 steps process and it involves a redirection

Look at these links (they are from templates manager, but same links are in all managers)

index.php?option=com_templates&task=style.edit&id=7
index.php?option=com_templates&view=style&layout=edit&id=7

• the 1st link is the clicked url, and makes the edit access check (and is checked-in check) by calling the controller edit task (and then redirects to the 2nd url)
• the 2nd link will display the edit form

In more details, when 1st link is queried by the browser, a call is made to edit() method (task) of JControllerForm

• which will call JControllerLegacy::holdEditId() that sets the ID into the session array: com_templates.edit.style.id

then browser is redirected to 2nd link that displays the form, and a check is made that the ID is inside
com_templates.edit.style.id aka it is editable

• also when you click close the ID is removed from the (session) array

If for any reason the browser or the proxy decides it is a good idea not to query the 1st link,
and instead directly go to the 2nd link , then of course the ID will not be found into session com_templates.edit.style.id aka you get the message "You are not permitted to use that link to directly access that page"

1 of reasons that browser can decide not to query the 1st URL, is this directive:
ExpiresDefault "now plus 1 hour"

• which includes text/html case too

you can see this behaviour in chrome, if you open browser tools and look at the network TAB you will see that the 1st link is retrieved from cache

libraries\joomla\application\web.php

public function redirect($url, $status = 303)

• it does not set cache headers

maybe add no caching for all non permanent redirections ?

// --Prevent-- browser / proxy caching for the case of 303 redirect
if ( $status==303 ) {
    $this->header("Cache-Control: no-cache, no-store, must-revalidate"); // HTTP 1.1.
    $this->header("Pragma: no-cache"); // HTTP 1.0.
    $this->header("Expires: 0"); // Proxies.
}

i am asking i do not know if this is good for all cases

Browsers themselves cache 301 redirects VERY hard. I really don't think it would make a difference

I am sorry i have not said it,
in our case Joomla is sending 303 (as expected)
[i have updated my code above]

i confirmed this opening the network TAB of browser tools, and viewing the headers, response is 303
some browser will decide not to cache (firefox) some will cache it (chrome)

i think add no cache headers for the case of not permanently moved (aka $moved is false) is safe ?

I'm not a developer, but it seems to occur after hitting the close-button.
Or just bad luck.

For what it's worth, I'll share my experience: I run admintools component on all my sites. As part of admintools, there is a config for .htaccess. One of the parameters controls default expiry time = 1 hour in headers. I turned this off and the problem disappeared. Not sure what's related to what but it definitely fixed it for me.

all that probably did was flush your local browser cache on the next page reload

Seems to have completely gone away as I navigate from article to article. Whereas before I was plagued with the error and could only operate with chrome inspector turned on (disabling cache).

Further proving that its a browser caching issue as having chrome dev tools open with cache disabled just disables the browser cache... it doesnt effect anything server side.

A new issue has been opened for this: https://issues.joomla.org/tracker/joomla-cms/9013

Also there can be a change (J4 ?)

• that does not involve changing the usage of the session which is a big compatibility break, but avoids the redirect
• it is still a compatibility break e.g. 3rd party extensions use earlier occuring events to examine current view (we may reduce compatibility break this by adding &view= to edit links)
• and it may create other problems (i don't know)

is to replace the redirect with view rendering:
https://github.com/joomla/joomla-cms/blob/staging/libraries/legacy/controller/form.php#L420-L424

// Check-out succeeded, push the new record id into the session.
$this->holdEditId($context, $recordId);
$app->setUserState($context . '.data', null);

$this->setRedirect(...);

with:

// Check-out succeeded, push the new record id into the session.
$this->holdEditId($context, $recordId);
$app->setUserState($context . '.data', null);

// Set view that will be rendered
$this->input->set('view', $this->view_item);

// Get the view configuration
$document = JFactory::getDocument();
$viewType   = $document->getType();
$viewName   = $this->input->get('view', $this->view_item, 'cmd');
$viewLayout = $this->input->get('layout', 'edit', 'string');
$viewTmpl   = $this->input->get('tmpl');

// Get/Create the view
$_view = $this->getView($viewName, $viewType, '', array('base_path' => $this->basePath, 'layout' => $viewLayout, 'tmpl' => $viewTmpl));

// Get/Create the model
$modelName = ucfirst($this->model_prefix).ucfirst($this->view_item);
$_model = new $modelName;

// Push the model into the view
$_view->setModel($_model, true);
$_view->document = $document;

// Render the view
$_view->display();

I never said removing the redirect could not be done, however that is a massive change which breaks a long established workflow rather than the small change to the closing of the session before a redirect which should address the race condition which only occurs on a tiny number of requests on bad webhosts. The redirect to a form happens in order places, not just on editing articles.

Any such major change, backward compatibility change, would need careful planning, implementation, and merging into a new series.

Its major work for so little gain.

@PhilETaylor
you are right it is of very little gain

But about setting no cache headers for 303 redirects, there is no compatibilty problem with it and in fact it is the expected behaviour that 303 redirects are not cached by browser unless explicitely told otherwise:

libraries\joomla\application\web.php

public function redirect($url, $status = 303) {
...
    // --Prevent-- browser / proxy caching for the case of 303 redirect
    if ( $status==303 ) {
        $this->header("Cache-Control: no-cache, no-store, must-revalidate");  // HTTP 1.1
        $this->header("Pragma: no-cache");  // HTTP 1.0
        $this->header("Expires: 0");  // Proxies
    }
...
}

I tested and adding the above, does work as a workaround (at least for Apache/2.4.10)

• for servers that are configure that are configured to cache HTML content via htaccess directive e.g. ExpiresDefault "now plus 1 hour"

The above default header, is used/set by the web server only if the page itself has not set cache related headers

The session_write_close() race condition is nothing to do with caching of redirects, its with the closing of the session before the loading of the page redirected to.

However if that page never gets invoked, because stupid browsers cached the url redirect, then this could also cause an issue.

However you are probably right that forcing browsers to reload the page before redirecting, instead of seeing the url and redirecting because of a cache - this might be a good change to make.

Can you write a PR and submit it please.

i will

actually I can add it to #9035

I have the problem when Cache is set to "ON - Progressive caching"
When OFF - I can open the article

To what Joomla version you upgraded? To Joomla 3.4.7 as per title of
this post? IF that is the case upgrade to Joomla 3.5.0 since providing
advise is a) on the forums and not here and b) not effective on outdated
software versions

Leo

On 3/30/2016 1:41 AM, tehribo wrote:

I have the problem when Cache is set to "ON - Progressive caching"

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#8757 (comment)

I can confirm this still happens in Joomla 3.5.1. A workaround is to check the box next to the item and click "edit" This will et you in even when clicking the title does not.

Confirmed as well. Been an ongoing issue followed all steps when in a single session you can click the title of an article once, if you save & close or Cancel and try to click on the article title again you get the "You are not permitted to use that link to directly access that page (#97)." (or what ever ID you are trying to edit.)

found the issue to be in Akeeba Admin tools .htaccess maker. there is an option that is defaulted to "Yes" Set default expiration time to 1 hour.

Change that to No if you are getting the issue and it will disappear!

found the issue to be in Akeeba Admin tools .htaccess maker. there is an option that is defaulted to "Yes" Set default expiration time to 1 hour.

That is not the root issue. The root issue is that browsers cache the intermediate page redirect. Browsers are dumb. You make this caching worse by enabling features of Admin Tools to not expire for long times.

The correct solution to this issue is a complete rewrite of the way the edit page is loaded, and this needs to be able to be loaded without the intermediate page redirect being cached by browsers.

By as usual 'Aint nobody got time for that' amount of recoding

So what about the issue 'You are not permitted to use that link to directly access that page' wich was the original question asked here. Will it be solved in the future, because i am using version 3.5.1 now and the problem still occurs?

To my knowledge, this issue has yet to be fixed and has been present in Joomla since pre-historic times. You can read much detail about it here: https://issues.joomla.org/tracker/joomla-cms/9013. Here is my comment that gets to the crux of the matter: https://issues.joomla.org/tracker/joomla-cms/9013#event-125916. The current state of the testing/analysis is shown here: #9035.

I, for one, would really like to see this fixed.

An issue that isn't consistently reproducible and relies heavily on factors that make it difficult to damn near impossible to reproduce isn't going to get top priority or even fixed in a timely manner. Sure, people can test pull requests to make sure no regressions slip in, but if nobody except for one person on this entire GitHub repo can consistently manage to reproduce this random issue the odds of anyone ever truly deciding the issue is "fixed" are slim to none.

Not trying to attack anyone or say it's not annoying (hell, nobody's really dismissing it as not an issue), but so far the only somewhat viable reproduction instructions are "click a bunch of stuff really quickly until you manage to get the error".

...so far the only somewhat viable reproduction instructions are "click a bunch of stuff really quickly until you manage to get the error".

Actually, that's what it seemed like initially, but I later ruled that out... it's not necessary to do it quickly.

It was easy to reproduce using SiteGround's demojoomla.org site, at the right time of the day (probably server load related). People argued that SiteGround was a crap environment, but I argued back that we are trying to reproduce an issue that is very difficult to reproduce in a non-crap environment, hence it's a good choice.

My comment of Feb. 6 explains:

@cpaschen we are trying to reproduce the problem and I have found that my SiteGround demo is a reliable way to do that. People are seeing this error in a variety of environments, but it is often very difficult to reproduce and therefor very difficult to test and try potential fixes. Both myself and @PhilETaylor have seen the issue come up recently on our client's servers. The one I observed was in the Rackspace cloud. Anyway, we are trying to flush it out and test it, not avoid it.

I have spent days and days on this before.

There are THREE different issues to resolve.

When I get time, I will document/fix all three - fixing one doesn't fix the problem.

The root problem is multi layered, involving session race conditions, server PHP processing and browser caching.

However at least one of the fixes has a MAJOR impact on API and Joomla internals, and so this is not a quick, simple, or pretty fix.

Thank you @PhilETaylor. I'll try to get my SiteGround testing going again, w/ specific instructions to reproduce.

Just to chip in. I get this error all the time. Exactly like the video. It seems to me to occur more frequently if you save and close an article and then try to go back into the same one again.

@uglyeoin

It seems to me to occur more frequently if you save and close an article and then try to go back into the same one again.

• you have not mentioned if you have checked the case, that was explained above, and i will repeat below

if you get this repeatedly for an article / record, that you already edited and closed once,

• then it means your browser is caching the 1st request that calculates the edit permission (2nd request displays the edit form layout)

Most usual reason for browser caching the 1st request is because your web-server was configured to send "cache-this" HTTP headers

Caching is only 1 part of this bug, but yes its a major part and can be further (negatively) effected by crazy/good .htaccess rules and web server configurations.

I'm consistently running into this issue at least on couple of our clients Joomla installations. My personal fix was simply to stop using Chrome as it's the only browser the bug happens on (for me). I'm now using backend from Firefox instead.

Also sometime around Joomla 3.6 patch at least one site started exhibiting this behavior that hadn't done it before. Of course the reason might also be new version of Chrome rather than the Joomla update.

If it's any use to post System Information from Joomla, just ask.

I have spent days and days on this before.
There are THREE different issues to resolve.
When I get time, I will document/fix all three - fixing one doesn't fix the problem.
However at least one of the fixes has a MAJOR impact on API and Joomla internals, and so this is not a quick, simple, or pretty fix.

Hi Phil, sorry to drag this up... just wondering if there was any further movement on this?

I will document/fix all three

I like the sound of that! More power to @normdouglas. Can we take a collection $$$ and stoke the fire?

For clarity, I'm not suggesting I've fixed it or have a fix... rather referencing some @PhilETaylor mentioned earlier.

Hello everyone...I have read through the forums, and understand this is a large problem at it's root. I am very much able to reproduce the same issue with the clear steps of opening an article/module, and then closing it and then re-opening the same one. A logout does provide a solution for re-opening it once, but then issue pops up again. Additionally, having cache disabled on my Chrome DevTools does solve the problem...but obviously can't expect my clients to do that!

I have just upgraded today to Joomla 3.6.5. Anyone have any update of at least a good temporary solution?

Hello Ridge, This is not a support platform. This list is to communicate
improvements to the Joomla CMS and systems.

Your question belongs on the forums so post on the forums in "general"
to get support

Thanks

Leo Lammerink
MD GWS-Global Web Services Ltd
Member J-CMS Release Team

On 1/4/2017 9:44 PM, Ridge Robinson wrote:

Hello everyone...I have read through the forums, and understand this
is a large problem at it's root. I am very much able to reproduce the
same issue with the clear steps of opening an article/module, and then
closing it and then re-opening the same one. A logout does provide a
solution for re-opening it once, but then issue pops up again.
Additionally, having cache disabled on my Chrome DevTools does solve
the problem...but obviously can't expect my clients to do that!

I have just upgraded today to Joomla 3.6.5. Anyone have any update of
at least a good temporary solution?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#8757 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHzLNqmOf-0q9Pgm4llrNzZnloDWhV3eks5rO7BfgaJpZM4G5yG2.

I was trying to help the movement of this issue, by confirming that the issue is still an issue with the latest Joomla version of 3.6.5.

I felt like I was keeping in tone with the rest of the forum on this page...really just wanted to see if anyone had found a good solution to this issue, which is an issue that needs to be improved on to the Joomla CMS and systems.

It is not an issue that has been confirmed on the Issue Tracker
https://issues.joomla.org/ nor in the JBS (Joomla Bug Squad so this
place is not the correct location to file support. If you consider this
a bug feel free to post an Issue on the tracker with link provided?

Leo

On 1/4/2017 9:59 PM, Ridge Robinson wrote:

I was trying to help the movement of this issue, by confirming that
the issue is still an issue with the latest Joomla version of 3.6.5.

I felt like I was keeping in tone with the rest of the forum on this
page...really just wanted to see if anyone had found a good solution
to this issue, which is an issue that needs to be improved on to the
Joomla CMS and systems.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#8757 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHzLNtz0ig4KmASf0A524EyHSt4evHz-ks5rO7PFgaJpZM4G5yG2.