Error after update to Joomla 3.4.7 You are not permitted to use that link to directly access that page (#xx)

revers28 commented 8 years ago

Steps to reproduce the issue

Update to joomla 3.4.7 Go to the view of the articles in the backend Try to edit an article in the backend bij click on title.

Expected result

You can edit the article

Actual result

You are not permitted to use that link to directly access that page (#xx)

Same issue when you go to templates

Steps to reproduce the issue

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

Expected result

Acces to the template

Actual result

You are not permitted to use that link to directly access that page (#xx)

System information (as much as possible)

PHP gebouwd op Linux v34011.2is.nl 3.13.0-042stab108.2 #1 SMP Thu Sep 17 11:38:20 MSK 2015 x86_64 Database versie 5.5.46-MariaDB-1~trusty Database collatie utf8_general_ci PHP versie 5.5.9-1ubuntu4.14 Webserver Apache WebServer naar PHP interface cgi-fcgi Joomla! versie Joomla! 3.4.7 Stable [ Ember ] 21-December-2015 16:00 GMT Joomla! Platform versie Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT Gebruikersagent Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Additional comments

PhilETaylor commented 8 years ago

Logout. Login. Fixed. As Per the FAQ!

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

level420 commented 8 years ago

@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!

level420 commented 8 years ago

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.

PhilETaylor commented 8 years ago

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.

PhilETaylor commented 8 years ago

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!

level420 commented 8 years ago

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

PhilETaylor commented 8 years ago

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

level420 commented 8 years ago

@PhilETaylor which browser are you using?

level420 commented 8 years ago

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

PhilETaylor commented 8 years ago

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.

level420 commented 8 years ago

And here is my screencast:

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

which shows the issue.

Kubik-Rubik commented 8 years ago

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

level420 commented 8 years ago

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.

oogloo commented 8 years ago

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

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8757.}

level420 commented 8 years ago

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

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

PhilETaylor commented 8 years ago

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 https://github.com/joomla/joomla-cms/issues/8755#issuecomment-166553422

level420 commented 8 years ago

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

jacklogic13 commented 8 years ago

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.

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8757.}

PhilETaylor commented 8 years ago

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

jacklogic13 commented 8 years ago

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

tampe125 commented 8 years ago

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.

photodude commented 8 years ago

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

gwsdesk commented 8 years ago

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

PhilETaylor commented 8 years ago

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

gwsdesk commented 8 years ago

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

PhilETaylor commented 8 years ago

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.

AlbertoSoliman commented 8 years ago

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

It's working good now for me

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8757.}

PhilETaylor commented 8 years ago

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

810 commented 8 years ago

seems to be fixed on the rc

izharaazmi commented 8 years ago

@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.

iscomputerman commented 8 years ago

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

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8757.}

PhilETaylor commented 8 years ago

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

techmerlin commented 8 years ago

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

PhilETaylor commented 8 years ago

@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)

infograf768 commented 8 years ago

Also

Database Collation latin1_swedish_ci

is wrong. It should be utf8.

techmerlin commented 8 years ago

@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.

ggppdk commented 8 years ago

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

ggppdk commented 8 years ago

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

wilsonge commented 8 years ago

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

ggppdk commented 8 years ago

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 ?

mbaggy commented 8 years ago

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

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8757.}

vmurphy commented 8 years ago

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.

PhilETaylor commented 8 years ago

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

vmurphy commented 8 years ago

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

PhilETaylor commented 8 years ago

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.

durian808 commented 8 years ago

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

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8757.}

ggppdk commented 8 years ago

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();

PhilETaylor commented 8 years ago

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.

ggppdk commented 8 years ago

@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

PhilETaylor commented 8 years ago

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.

joomla / joomla-cms