@ggppdk See CS PR ggppdk#1

@wojsmol
thanks, for the code styling fix,

next time i will use try to use
https://github.com/joomla/coding-standards

About testing this PR

• apply it to your local repository
• then edit file https://github.com/joomla/joomla-cms/blob/staging/libraries/legacy/controller/legacy.php#L903

and add a

return; 

at the start of the function, thus the id will never be added into the session as editable,
then test all backend screens: articles, categories, etc for being able to edit the records and save the edit form

I can confirm having tested this on 3 3.5.1 installations that this worked for me with following modules issue:
Install of 3.5.1, logout/login did not fix issue in this instance.
Using front end editing with open in administrator on in module config.
When press EDIT button on module on front end template, would ALWAYS get permission error message. You are not permitted to use that link to directly access that page (#'module number').
.. im not sure if its a certain combination of plugins/login items we are using causing it to happen in every case for us.
Hoping this gets put into next release asap as this is very annoying for those using front end editing.

@edzz83

Hoping this gets put into next release asap as this is very annoying for those using front end editing.

that is one way, every one that needs a fix copying the suggested code into their web-sites

• since you have tested this, you should mark your test as successful here:

https://issues.joomla.org/tracker/joomla-cms/10753

by clicking on the button "Test this" button, and selecting "Test succesfully",

if you and other just copy the code but don't mark test as successful then it will not be accepted

I have tested this item ✅ successfully on 80a5498

Tested on 3 installations we run (sites we have built from scratch running multiple components and such). Fix worked on all 3 sites successfully. This issue appeared from us when trying to edit a module on front end with it set to 'administrator' mode (so when clicking edit it should open module in administrator) this would come up with the error every time regardless of browser cache status. The fix resolved this issue.

@PhilETaylor can you test this please

Peeking in here after a long time not looking at this. One question that comes to mind is, has @ggppdk 's fix been tested in an environment where the "You are not permitted..." issue is easily reproduced? Because if not, testing the fix has no meaning. Also, just a general comment from someone (me) who is not intimately familiar with what is going on internally here as relates to the user session and the editing task: just as with any other operating system, it makes sense to lock the resource (e.g. the "article" when editing it), so that the same user (or other users) can't open the same resource while it's locked. [ See: https://issues.joomla.org/tracker/joomla-cms/9013#event-125916 ] This is what has to be fixed, right? Can we get some group consensus agreement on that? Adding a patch to "avoid" something is not the right way to go about this. It needs to be coded correctly, even if that takes time and is something that can't be immediately folded into the next release. And now, I am ready for all the insults that will be hurled at me from the Joomla cronies. Have a great day!

@mbabker

... and just has a single controller.php file

... the code is inside checkEditId() and it is for classes inheriting from JControllerLegacy

Please provide an example (steps) that this code will do something worse than what is currently happening

• thus i can improve this PR, testing the case that you have in mind

Also, is it really necessary to instantiate another controller to get the data you need with this implementation?

Yes it is because the controller that made the check is in generally different than the current controller (as far as i remember when making this PR)

@durian808

One question that comes to mind is, has @ggppdk 's fix been tested in an environment where the "You are not permitted..." issue is easily reproduced? Because if not, testing the fix has no meaning.

• If something has not been tested, then there is no meaning to try test it, ... aaa ... hhhmm ... ok ... i will figure it out eventually ... still thinking ... no ... i don't understand

but to answer your question Yes and you can create such an environment yourself please read my other messages about forcing the "easily reproduced" thing by instructing browser to cache the 1st request

Adding a patch to "avoid" something,

The term is "fault-tolerant" sound better ?
a fault will occur try to recover from it , the best way possible
Let's not play with words,

• are "recover" or "prevent" a better title ?

@mbabker

the solution i have in my extension is to make the checks in the same step that instatiates the view without a redirection

• i almost made a PR for this

it was working for core components, but it was really breaking B/C (really bad break)

Right, I get this method is in the base controller, but your logic for
instantiating the second controller assumes ContentController would never
have an edit task like ContentControllerArticle, just as an example. Which
is probably true, but it still feels wrong to introduce something with
partial class logic.

As for the second controller thing, can you point out how that's
happening? JControllerLegacy::getInstance() only supports a single
controller instance for the entire app so you can't use that to create two
controllers and unless I've missed something somewhere there isn't any
other code manually instantiating new controllers outside that for the
legacy MVC tree.

On Monday, August 1, 2016, Georgios Papadakis notifications@github.com
wrote:

@mbabker https://github.com/mbabker

... and just has a single controller.php file

... the code is inside checkEditId() and it is for classes inheriting
from JControllerLegacy

Please provide an example (steps) that this code will do something worse
than what is currently happening

• thus i can improve this PR, testing the case that you have in mind

Also, is it really necessary to instantiate another controller to get the
data you need with this implementation?

Yes it is because the controller that made the check is in generally
different than the current controller (as far as i remember when making
this PR)

@durian808 https://github.com/durian808

One question that comes to mind is, has @ggppdk
https://github.com/ggppdk 's fix been tested in an environment where
the "You are not permitted..." issue is easily reproduced? Because if not,
testing the fix has no meaning.

• If something has not been tested, then there is no meaning to try test it, ... aaa ... hhhmm ... ok ... i will figure it out eventually ... still thinking ... no ... i don't understand

but to answer your question Yes and you can create such an environment
yourself please read my other messages about forcing the "easily
reproduced" thing by instructing browser to cache the 1st request

Adding a patch to "avoid" something,

The term is "fault-tolerant" sound better ?
a fault will occur try to recover from it , the best way possible

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

Wait, I just realized this is the second check after the redirect. So ya,
there is a second controller invoked.

On Monday, August 1, 2016, Georgios Papadakis notifications@github.com
wrote:

@mbabker https://github.com/mbabker

the solution i have in my extension is to make the checks in the same step
that instatiates the view without a redirection

• i almost made a PR for this

it was working for core components, but it was really breaking B/C

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

but it still feels wrong to introduce something with partial class logic.

The solution should work in 99% of cases, i say this percentage, since the code is inside checkEditId(), and inside JControllerLegacy,

• if the functon call to allowEdit() needs more parameters to work ! then it should be the responsibility of the 3rd party developer to override the function and extend it, and call proper code, i speak of 3rd part apps that may have an overriden allowEdit(), that receives more parameters, or using some other function
• furthermore, even if in some 3rd party the new code triggers a failure, then it will be triggered on an already erroneus situation, and not in normal situations

JControllerLegacy::getInstance() only supports a single controller instance for the entire app

• yes you are right, that is why the code does not use it, instead it does:

$controller = new $controller_name;

@ggppdk:

but to answer your question Yes and you can create such an environment yourself please read my other messages about forcing the "easily reproduced" thing by instructing browser to cache the 1st request

@edzz83:

Tested on 3 installations we run (sites we have built from scratch running multiple components and such). Fix worked on all 3 sites successfully. This issue appeared from us when trying to edit a module on front end with it set to 'administrator' mode (so when clicking edit it should open module in administrator) this would come up with the error every time regardless of browser cache status. The fix resolved this issue.

I didn't see this before from @edzz83... look's good. I will attempt to test this on a SiteGround free site. Other testing I did on SiteGround always produced this error very easily.

Tried to do a simple thing... created an account at demojoomla.com. I can't log into the front end now, getting "The most recent request was denied because it contained an invalid security token. Please refresh the page and try again." None of the usual tricks clear this state. This is Joomla 3.6.0. Also something very strange... I created a blog category with 3 articles in it. When I go to the blog, usually I see only one article. Occasionally I see 3 as it should be. Dunno what the heck is going on. My demo site is here: http://durian0816.demojoomla.com/index.php

Update: I tried again after about 40 min. to log into the site, and it let me log in – once. Then reverts back to "The most recent request was denied because it contained an invalid security token. Please refresh the page and try again." ... and no way to leave this state. The business with the blog only showing one article has mysteriously fixed itself.

I finally was able to do some testing on the demojoomla.com site. I was able to log into the front end and perform the usual test of editing a blog article, then saving, then repeating. I was not able to produce the "You are not permitted..." issue. I will try again tomorrow.

To reproduce this problem all you need to do is have Apache server configured to add Cache and Expires headers on the HTTP responses. Then in Joomla just open a module and then close it, and try to open it again.

I tested this PR and it solves the problem, even with Cache and Expires headers.

A couple comments:

1) Would it make sense, as an additional precaution, to force PHP to set the HTTP headers specifically for redirect responses?

<?php
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
?>

2) Would it make sense to use HTTP response code 302 instead of 301 or 303? Even in cases when the server doesn't have Cache and Expires headers, the browser may proactively cache 301 and 303 redirects, but not 302 responses.

I hope this is useful.

CASE 1: The initial "edit-task", failed to update session properly, due to race-conditions
CASE 2: The initial "edit-task", was never called because the HTTP request was cached by the browser for any reason

Exactly what Ive been saying for years...

Although this PR will help a little, IMHO its not production ready, and is the wrong approach to the problem.

The MAIN issue is CASE 2 above.

Reworded: its the The initial "edit-task" - [that checks out an item and locks it], was never called because the [initial] HTTP request [on clicking the edit link/button] was cached by the browser [previously] for any reason, [and so the check out is never conducted, and the browser skips direct to the Edit Form page, which fails because the item is not checked out, and so that in turn redirects back to the item list with the error message about permissions]

This is a KNOWN Google Chrome issue mainly https://bugs.chromium.org/p/chromium/issues/detail?id=91740

A 301 redirect (without "Expires" header) will be cached FOREVER in Google Chrome!

IMHO the correct approach is more down the line of ensuring that Joomla's internal redirects are not 301 redirect that can be cached.

I have spent considerable time debugging this issue, and researching solutions to the issue, and attempting to do do just this - however after the personal attacks, I washed my hands of it.

Pssst.... see this PR that was never merged.... https://github.com/joomla/joomla-cms/pull/9035/files cough cough...

IMHO the correct approach is more down the line of ensuring that Joomla's internal redirects are not 301 redirect that can be cached.

not possible, please correct me, but you can not override all caching cases, that happen due to configuration in .htaccess, (maybe it is possible in some server configurations ? i am not sure, someone please comment if it is possible and provide documentation link)

About if this fix is correct approach ...

• it runs code that was supposed to have run already

1. check if editable / not checked out
2. add to session as editable and marked it as checked out

Thus i argue it is not bad approach in what it does

The thing i do not like about this PR and any PR that will depend on the 2nd call, was not mentioned by anyone, and is this

That it will encourage BAD .htaccess configurations that do this kind of caching, which may create similar problems to other cases too that will need similar patching.

• If it was only the rarely occuring issue of this message due to race conditions (which is not that important since you can re-click to edit the record) then this PR would be more easy to accept and also more easy to remove later too, but if this PR encourages such .htaccess configurations, removing it later will create problems !! because more and more web-sites will start to depend on it and use such .htaccess configurations

Please decide something,

• for me, a BEST solution is to improve the message too, which is really wrong:

You are not permitted to use that link to directly access this page

It is totally wrong for the user, it means nothing to the user, it does not inform the user of the real reasons. It is a message for programmers that have studied Joomla code

Proper:

Edit request has failed temporarily. Please try again.

If this is repeated for the same record multiple times, then it means that your server has been misconfigured and tells browser to cache edit requests.

Please contact your administrator to disable caching via HTTP headers (e.g. in .htaccess)

ok, not exactly the above, but something like it

I am still not seeing the issue come up on my SiteGround test, however that could be because of the load on the server. In the testing I did back in Feb. this year, I noticed that I could reproduce the issue very easily when the load on the server was apparently higher (the SiteGround server is located in Chicago). I will try again in 3 hours... 7pm Chicago time.

I seem to be running into the same "Invalid token" type error as I did in Feb., when attempting to log out and back in again. [UPDATE: I disabled the jSGCache plugin and this eliminated the problem. I was also seeing some other strange effects when this plugin was enabled (by default).]

PLEASE read this re: what messages would be appropriate (from my comment Feb. '16):

I still think the resource (article) should be locked, as I was saying in #9013... "...one edit request on top of an unfinished one, causing session data corruption, followed by a 403 error because Joomla gives up." If the previous edit has not been completed (content saved), and the same user is clicking the edit button again, they should get a message indicating "Previous save not completed yet. Please retry." While a lock exists on the article, a read-only status could be read to indicate "save in progress" or "open for editing". For the later, the message to the user would be "Article already checked out (not saved)," and the user would then be warned that edits could have been lost and to "click here" to edit the article again (thereby losing those edits). Note that this is already the behavior of Joomla – if the editing session is lost by virtue of losing the browser tab or window, a subsequent click on the edit icon reloads the last saved content. With my suggestions here, at least the user is given feedback as to what's going on and prevented from opening an article when a save operation has not yet completed.

See also: #9035 (comment)

Any error message should be written in non technical language and be the
minimum information needed. A technical essay is not appropriate for an
error message

I was able to reproduce the problem on the SiteGround demo site. I was testing between about 7:45pm and 8:20pm Chicago time. Here is the screen movie:

http://durian0816.demojoomla.com/screen_recording_0802-3b.mp4

Here is the demo site:
http://durian0816.demojoomla.com

username: guest
password: guest123+

i was able to reproduce the problem on the SiteGround demo site.

and ? i mean what is new ?

and ? i mean what is new ?

Well, reproducing this in an environment that anyone can have access to, without needing special configuration of Apache... this is a good thing and worth mentioning again.

My next step is to try out your code changes.

I can replicate the issue reliably with articles. I can solve the issue by opening Chrome devtools with the option 'Disable cache (while DevTools is open)' set to checked. As soon as I close devtools the issue returns.

To replicate:
1. Joomla caching off, server caching off (no siteground speeder-thingy), .htaccess cache set to 'Header set Cache-Control "max-age=518400, must-revalidate", have AdminTools installed with its .htaccess customizations.
2. In admin, open an article for editing, Save & Close the article
3. Open the article for editing again, note the error message "Error You are not permitted to use that link to directly access that page (#95)." where the #95 is the article id.

To resolve:
1. Add the listed code to /libraries/legacy/controller/legacy.php
2. Log out and log back in.
3. Repeat the replication steps, no error message.

I can set up a copy of this site for a short while with a couple of people if it helps.

hmm can we get this to a final PR it looks like it fixes some problems with caching and chrome e.g. #8042 but it looks like this is not the best correct fix? Or do i missread the comment above?

it fixes some problems with caching and chrome

yes, it work

but it looks like this is not the best correct fix

yes, because it will encourage browser caching being enabled on all pages,
if this accepted then with time more sites may come to depend, and thus later reverting it (if proven problematic) will be difficult

thinking of this, i think best solution is the simple old (and good) solution, make the URLs unique on every page load adding a timestamp to each of them

• anyway these URLs that will have the unique timestamp variable per load, just calculate access , they do not produce HTML , and instead they are only a redirect, so they will not even waste any browser caching space

I think make a new PR that creates unique URLs and then close this PR

I think make a new PR that creates unique URLs and then close this PR

Thanks i will be happy to test!

thanks everyone for continuing to work on this. I have not been able to test... too busy these days.

I tested this patch with staging and the patch tester. I successfully replicated the issue, then applied the patch. Here are some observations:

1. I replicated the issue once after patch application, before doing anything else
2. I logged out then logged back in and replicated the issue.
3. I cleared cookies and browser cache, then replicated the issue.
4. I opened an article, then clicked cancel, opened the article again, issue was not replicated (this is same behaviour as pre-patch).
5. I opened an article, then clicked save & close, opened the article again, issue was replicated.
6. I opened Chrome Devtools (cache disabled), then opened an article, clicked save & close, opened the article again, issue not replicated (same behaviour as pre-patch).
7. I closed Chrome Devtools, then opened an article, clicked save & close, opened the article again, issue NOT replicated.

So I'm not the expert on devtools or apparently browser caching, but what difference does it make to have saved the article once with devtools open in order for the behaviour to then disappear?

@gaelicwinter My default when dev tools is open is "disable cache" enabled (Google Chrome) this would fix the caching issues because caches are not used when that option is enabled in dev tools

I didn't like @gwsdesk's comments over at #8757, and that item has been "locked and limited," which I also don't like. @gwsdesk should have referred @ridgerobinson to this tracker item. What say you, @brianteeman?

Hey @durian808...thanks for thought. I figured I may have been out of context, not sure. I was actually able to find a "solution" about 30 mins ago. I just recreated a new joomla installation, and copied my database over...and included all folders from my original source (but not any of the .htaccess or configuration.php, etc). Surprisingly, the issue was resolved. I figured it may have been a bad table in the database that got sorted when I copied the database...but wasn't too sure.

I think I saw some other comments where people did try a fresh Joomla install and still had issues, however. Wish I could help more.

@ridgerobinson, thanks for your input. Your view of the issue may just be hiding for the moment. I have shown that the issue appears to be sensitive to server load. It may be a good idea to save your previous installation and database, in case the problem never comes back for you, because the saved ones might provide a clue. This issue has been essentially impossible to reproduce in some environments, and easy to reproduce in others – for some people.

Imho, this goes against the whole point of the separate edit task that redirects to the view task.
If we are going to check edit permissions at that stage, then why even do it in a separate task with a redirect beforehand? Makes no sense to me.

What you try to achieve @durian808 ? I do not keep following each thread
buddy (especially not where the last issue was discussed in October 2016
and successively locked by the pepople who have the right to do so and
don't tell me what I should and should not please? If a Joomla user asks
support here (and that is how it sounded) we per definition send him/her
to the Joomla-forums. I am not aware that we have changed this. Besides
that I am the wrong person to complain about what you like or don't like
about limitations. I have no rights to limit or lock discussions here so
find the correct person to complain about?

On 1/5/2017 2:25 AM, durian808 wrote:

I didn't like @gwsdesk https://github.com/gwsdesk's comments over at
#8757 #8757, and that
item has been "locked and limited," which I also don't like. @gwsdesk
https://github.com/gwsdesk should have referred @ridgerobinson
https://github.com/ridgerobinson to this tracker item. What say you,
@brianteeman https://github.com/brianteeman?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10753 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHzLNo7I97r-T9oV7VHU8EJGlsHl8nrfks5rO_JHgaJpZM4IwcBB.

I have closed this PR,
for reasons for closing and for an alternative and maybe better solution
see my answer here:
#10753 (comment)

I'm sure I speak for a great many people who would like to know if this issue has been solved. That is what I try to achieve, @gwsdesk. By solved, I mean in the current version of Joomla. Or, is the solution planned for a future version of Joomla? I take offense to people who claim this is not an issue, bug, defect, or shortcoming. It is. Pick your word for it. Please let us know, in plain language, when this will be fixed and how we can help if we can. Thanks.

Please let us know, in plain language, when this will be fixed and how we can help if we can.

I can't reproduce the issue on my end. So if you want to help get it fixed, open an issue with clear instructions how it could be reproduced.

My feeling is that this comes a wrong caching. That may be a bug in a browser or a wrong server setting. The redirect we do in Joomla is a 303 "See Other" which shouldn't be cached by the browser.

@durian808 I cannot reproduce the issue as well as already expressed in the referred thread #10753 . I believe you when you tell the world that you are experiencing this issue but again posting access details to your Siteground or joomla.com account won't help you resolve this issue which has not been identified as a bug or whatever you wish to call it by the JBS nor the CMS Release Team so only if we can replicate this by following steps to reproduce as Thomas mentions we can start working on a solution

Steps to reproduce the error:

Environment
Ubuntu 14.04
Apache 2.4.7
MySQL 5.5.53
PHP 5.5.9

apache2.conf settings (different from fresh installation)

MaxKeepAliveRequests 0
<Directory /srv/www/>
    Options FollowSymLinks
    AllowOverride all
    Require all granted
</Directory>
# Browser Caching #
ExpiresActive On
ExpiresDefault "access plus 30 days"
ExpiresByType text/html "access plus 15 minutes"
Header unset Last-Modified
Header unset ETag
FileETag None

Steps

• Fresh Joomla 3.6.5 installation
• Log in to Administrator
• Go to Modules
• Click on the Breadcrumbs module
• Click Save & Close
• Click on the Breadcrumbs module again
• You get the error message You are not permitted to use that link to directly access that page (#17). and the list of modules is displayed again
• If you click on the Breadcrumbs module again no warning or error message is displayed this time and it shows the list of modules again

You can view the sequence of HTTP requests and responses here:
http://imgur.com/a/h8QJe

1. Display list of modules
   GET: ?option=com_modules
   Response: 202

2. Click on Breadcrumbs module:
   GET: ?option=com_modules&task=module.edit&id=17
   Response: 303 / Location: ?option=com_modules&view=module&layout=edit&id=17
   GET: ?option=com_modules&view=module&layout=edit&id=17
   Response: 202

3. Save & Close module
   POST: ?option=com_modules&layout=edit&id=17
   Response: 303 / Location: ?option=com_modules&view=modules
   GET: ?option=com_modules&view=modules
   Response: 202

4. Click on Breadcrumbs module again:
   GET: ?option=com_modules&task=module.edit&id=17
   Response: 303 / Location: ?option=com_modules&view=module&layout=edit&id=17
   GET: ?option=com_modules&view=module&layout=edit&id=17
   Response: 303 / Location: ?option=com_modules&view=modules
   GET: ?option=com_modules&view=modules
   Response: 202

So, the first question is why request ?option=com_modules&view=module&layout=edit&id=17 produces a 202 response the first time, and a 303 response the second time redirecting to the modules list?

The second question is why requests with 202 responses include the heading Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 but the same heading is not enforced on 303 responses?

It seems to me that the browser caching issue comes after these initial problems, and it just makes it worse by getting the browser stuck in using the same cached 303 response.

In my opinion this is a real bug and it should not be dismissed.

Except for one person, nobody's tried to dismiss it. But as this and other threads have pointed out it's not exactly the easiest thing to reproduce.

So, the first question is why request ?option=com_modules&view=module&layout=edit&id=17 produces a 202 response the first time, and a 303 response the second time redirecting to the modules list?

That's coming from the browser or web server configuration, not Joomla. Joomla doesn't have response caching like this. That is in part why this issue exists.

The second question is why requests with 202 responses include the heading Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 but the same heading is not enforced on 303 responses?

Depends if it's Joomla or something else issuing the redirect I guess. If it's Joomla issuing the redirect then perhaps the right headers aren't being attached (JApplicationWeb::redirect() doesn't send the full header set the same way a "regular" response does, the cache headers are set at JApplicationWeb::respond()). Anything that's not in the scope of the Joomla code I'm not even going to start speculating about.

So nice one but allow me to reply with a first simple question:

Environment
Centos 7.2
Apache 2.4
5.5.5-10.1.13-MariaDB-cll-lve
PHP 7.1.0
Server API FPM/FastCGI

None of what you describe is happening to any site on our servers nor on
some client servers located at major hosting providers
(Liquidweb/Bluehost/Hostgator to mention a few) so I cannot replicate!

what we have on Modules "not save etc" is widely commented on the Joomla
forums and has been identified by contributor Sozzled among others and
he is right : https://forum.joomla.org/viewtopic.php?f=709&t=937052
(READ THE ENTIRE THREAD PLEASE!)

This issue is confirmed by me as well as described by Sozzled and is
therefore as described not a Joomla issue imho

Leo

On 1/6/2017 10:43 PM, lyquix-owner wrote:

Steps to reproduce the error:

Environment
Ubuntu 14.04
Apache 2.4.7
MySQL 5.5.53
PHP 5.5.9

apache2.conf settings (different from fresh installation)

|MaxKeepAliveRequests 0 <Directory /srv/www/> Options FollowSymLinks
AllowOverride all Require all granted # Browser Caching #
ExpiresActive On ExpiresDefault "access plus 30 days" ExpiresByType
text/html "access plus 15 minutes" Header unset Last-Modified Header
unset ETag FileETag None |

Steps

• Fresh Joomla 3.6.5 installation
• Log in to Administrator
• Go to Modules
• Click on the Breadcrumbs module
• Click Save & Close
• Click on the Breadcrumbs module again
• You get the error message /You are not permitted to use that link
  to directly access that page (#17
  #17)./ and the list of
  modules is displayed again
• If you click on the Breadcrumbs module again no warning or error
  message is displayed this time and it shows the list of modules again

You can view the sequence of HTTP requests and responses here:
http://imgur.com/a/h8QJe

Display list of modules
GET: |?option=com_modules|
Response: 202

Click on Breadcrumbs module:
GET: |?option=com_modules&task=module.edit&id=17|
Response: 303 / Location:
|?option=com_modules&view=module&layout=edit&id=17|
*GET: |?option=com_modules&view=module&layout=edit&id=17|
Response: 202*

Save & Close module
POST: |?option=com_modules&layout=edit&id=17|
Response: 303 / Location: |?option=com_modules&view=modules|
GET: |?option=com_modules&view=modules|
Response: 202

Click on Breadcrumbs module again:
GET: |?option=com_modules&task=module.edit&id=17|
Response: 303 / Location:
|?option=com_modules&view=module&layout=edit&id=17|
*GET: |?option=com_modules&view=module&layout=edit&id=17|
Response: 303 / Location: |?option=com_modules&view=modules|*
GET: |?option=com_modules&view=modules|
Response: 202

So, the first question is why request
|?option=com_modules&view=module&layout=edit&id=17| produces a 202
response the first time, and a 303 response the second time
redirecting to the modules list?

The second question is why requests with 202 responses include the
heading |Cache-Control: no-store, no-cache, must-revalidate,
post-check=0, pre-check=0| but the same heading is not enforced on 303
responses?

It seems to me that the browser caching issue comes after these
initial problems, and it just makes it worse by getting the browser
stuck in using the same cached 303 response.

In my opinion this is a real bug and it should not be dismissed.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10753 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHzLNntKAKVAZvRg72y84EumvzY-HT2fks5rPmEGgaJpZM4IwcBB.

The problem with this issue is everyone thinks they are an expert. Personal abuse and attacks have meant I have whashed my hands of providing the solution for this issue many times.

Those that have taken the time to truly understand and get to the bottom of this real issue understand that there is a real issue to resolve, which is compounded by browser caching.

I have spent weeks researching and documenting this SPECIFIC issue - however the "solution" is that EVERY Joomla edit link that redirects to an edit form needs to be revisited and its redirect done in a non-cacheable way.

Im not going to repeat what I have already stated many many times. This is a real issue, but one that can simply be resolved with correct/different Apache settings for the time being, the ultimate fix will take a long time to develop and test. Especially as those that confess to be experts at testing, are not taking the time to fully understand the root issues.

This issue is confirmed by me as well as described by Sozzled and is
therefore as described not a Joomla issue imho

Rubbish. This is a Joomla issue, one that can be fixed and will be fixed. Like I said, everyone thinks they are an expert.

Cough Cough - READ #10753 (comment)

@PhilETaylor can you provide an example of how to fix an edit link? I am no expert but I am happy to help with this issue, if I can get some direction from you or @ggppdk. You both seem to have an understanding of the problem and its solution.

@PhilETaylor why have you not proposed (!) a solution yet knowing so (seemingly) well what the issue is as you emphasize ..... Curious ?

Simple. Fed up of idiots and personal attacks
Also if you check your fact, research this issue, you will see I have accurately described the issue and proposed - in words - solutions many times

On 6 Jan 2017, at 16:37, Leo Lammerink notifications@github.com wrote:

@PhilETaylor why have you not proposed (!) a solution yet knowing so (seemingly) well what the issue is as you emphasize ..... Curious ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Oh Phil...I do follow you believe it or not......Yeah you described that in "CASE 2: " https://github.com/joomla/joomla-cms/pull/10753#issuecomment-236978677 Question is why nobody followed up on that?

CASE 1:

• The consistent reproduction due to server (e.g. .htaccess) configurations, that instruct the browser to cache the redirect,

CASE 2:

• Quickly (middle) clicking in 10 / 15 edit links and thus having the RACE-conditions with the session data being overwritten so you can get some failures

Solution

CASE 1:

• This is server configuration, we can only be worked-around by like this PR tries to do, or just make some only documentation about it and every time some asks or googles the issue , then the documentation can be found, and thus fix his/her server configuration problem

CASE 2:

• It is just a small rare annoyance, when people try to open many edit links in very short time, it can be documented too

So besides the above,
I confirm what @lyquix-owner said

The 303 redirect response , that redirects from edit-task to edit-layout ("view") is missing both headers:
Pragma: no-cache
Expires: ...

Which brings us to the 3rd case??
of some rare cases that chrome can decide to cache the redirect ?
could it be because of the above headers missing ?

• if the above is true then this last 3d case can be addressed

A small suggestion (bear in mind I am no expert). Add the following lines to

libraries/joomla/application/web.php, line 542:

$this->header('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0');
$this->header('Pragma: no-cache');

This adds the headers on all redirects. Problem solved. I am unaware of issues that this may cause. Experts can weigh in.

This adds the headers on all redirects

Which is why it is a bad idea :-)

This adds the headers on all redirects
Which is why it is a bad idea :-)

The place to add it is here:
https://github.com/joomla/joomla-cms/blob/staging/libraries/legacy/controller/form.php#L420
and similar in other controllers

Like this:

header('Expires: Wed, 17 Aug 2005 00:00:00 GMT');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Cache-Control', 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0');
header('Pragma: no-cache');

$this->setRedirect(
	JRoute::_(
		'index.php?option=' . $this->option . '&view=' . $this->view_item
		. $this->getRedirectToItemAppend($recordId, $urlVar), false
	)
);

The place to add it i

wrong again :-)

There is a Response/Redirect API within the Joomla API, this should be configurable to output the correct headers when used...

Blindly outputting response headers in controllers and models is so not the right way of doing things...

There is a Response/Redirect API within the Joomla API, this should be configurable to output the correct headers when used

Until someone extend that to incorporate such functionality, the only way to do it is the one @ggppdk proposed. My 2c

wrong again :-)
There is a Response/Redirect API within the Joomla API, this should be configurable to output the correct headers when used...

No no

• currently , the only way to do it , is the way i suggested above

because JApplication::redirect is either bogus or at least let's say "incomplete"

You cannot use (due the current implementation of JApplication::redirect())
Neither:

JFactory::getApplication()->allowCache(false);

nor:

JFactory::getApplication()->setHeader('...', '...', true);

Because both the variables that are set by the above methods, both of them are ignored by JApplication::redirect()

even if you use
JFactory::getApplication()->setHeader('...', '...', true);
then you still need to call:
JFactory::getApplication()->sendHeaders()

• which will prevent JApplication::redirect() from setting any headers because it does a "check-headers-sent"

Best solution is to "fix" JApplication::redirect()
to

1. use JFactory::getApplication()->setHeader() for adding its headers
2. use in it JFactory::getApplication()->sendHeaders()

Best solution is to "fix" JApplication::redirect()

Bingo! Stop thinking about local hacks and fixes, these aren't your extensions you're working with folks. Fix core the "right" way.

Bingo! Stop thinking about local hacks and fixes, these aren't your extensions you're working with folks. Fix core the "right" way.

Yes, and also fix JApplication::redirect()
to respect the setting set by:
JFactory::getApplication()->allowCache(...);

Thank you @PhilETaylor and @mbabker. As I recall, Phil understood my input on this subject, and he knows a lot more than me about the internals of how edit sessions are handled and how this issue can be fixed. Yes, we need something very reproducible. I was gravitating toward the SiteGround demo as a way to reproduce, because I could consistently do so, and everyone has access to SiteGround. My viewpoint of this issue is that it's not a horrible thing, but it is annoying when it crops up out of the blue, and of course it really should be fixed once and for all. It's one of those things that, when the average Joomla user sees it crop up, it gives them a sense that Joomla is not 100% solid, and the error message produced is essentially meaningless. FYI, there's a lot of valuable information in all the past pull requests related to this issue.

How about: on libraries/joomla/application/web.php, line 542, add:

if(!JFactory::getApplication()->allowCache()){
    $this->header('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0');
    $this->header('Pragma: no-cache');
}

No. Wait one moment.

Please close this as we have PR #13516 which ultimately resolves this with ease.

Please close this as we have PR #13516 which ultimately resolves this with ease.

It does not solve the race issue, which is apparently a separate issue that generates the same error message. Please see comments in #13516.

Open a new issue for that. Thanks.

Out of nowhere, while we are busy adding modules, working on some menus, adding articles, and there is a request to edit a long time existing module then suddenly we encountered this error.

Tried to log out, clear all cache - Joomla and browser. Empty the session table but not luck

I change the Administrator's template and I can confirm that this fix the problem on my side.

Can someone try also to change Admin template and edit those article or module?

@orphicpixel please see #13516. The error is very sporadic and difficult to reproduce. Please retest when Joomla version 3.7.0 comes out.