Closed revers28 closed 8 years ago
Logout. Login. Fixed. As Per the 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 https://github.com/joomla/joomla-cms/issues/8755#issuecomment-166553422
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.
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
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:
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
In more details, when 1st link is queried by the browser, a call is made to edit() method (task) of JControllerForm
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
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"
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)
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 ?)
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)
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.
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