I have tested this item ✅ successfully on 1d28e54

YOU CANNOT test this on a server you dont have full access to - like Site Ground demo, people (like @durian808) will not be entertained in this PR comments should they attempt to rail road the comments again. Personal attacks will not be tolerated either.

As most of you know, I was able to precipitate this problem easily on the SiteGround server, without any special setup. Let's say I set up another test on SiteGround. Then I apply Phil's fix and see if I can precipitate the problem. Why is that not a good idea?

Also, what if Phil has found a reliable way to precipitate the error message, but there are other situations that cause this issue to appear. Phil, are you saying that you have ruled that scenario out? If so, how can we be sure?

thanks

people (like @durian808) will not be entertained in this PR

I refer to my comments in #9013 - where you showed your true colours, clearly stated you "don't know" how to test Pull Requests and "need to be walked through it" - specifically you showed you are nothing but a troll and dont respect those that invest considerable amounts of time to bugs like these or the Joomla project.

You are not welcome in this thread.

It is because of you, and you alone, that I lost all interest and enthusiasm for this issue the last time.

This PR fixes the issue - Fact.

You dont need to comment on this thread, if you are serious about testing it then follow the instructions above and at https://docs.joomla.org/Testing_Joomla!_patches and report your findings using the tool provided at https://issues.joomla.org/

This will be my last reply, ever, to you.

@durian808

As most of you know, I was able to precipitate this problem easily on the SiteGround server, without any special setup

The "without any special setup" case,
is not fixed in this PR (rare / random case occurence of the error),
identified as "RACE conditions" during updating user session

so you do not need to post here that it does not work in some rare / random cases,

The cases that should be fixed by this PR, are due to browser caching the redirect to the edit form

• either due server configuration sending default HTTP headers instructing browser to cache
• or due to missing headers regarding cache behaviour, some browsers , sometimes deciding to cache the redirect

@ggppdk I have been unable to replicate a TRUE race condition relating to this ever. Therefore I believe it can be ruled out.

I tested for a whole day with a session over 16Mb in size (after reconfiguring/recompiling PHP - gulp)

have been unable to replicate a TRUE race condition relating to this ever. Therefore I believe it can be ruled out.

hhmm, i am just saying that this PR is good in fixing the caching case, the RACE conditions issue is irrelevant to fixing caching it is simply a different cae

to explain more about race conditions, i mean this:

In Joomla articles manager

• during 6-8 seconds, quickly middle click (to open in new browser TAB / Window)
  on 20 article editing links

Some of them will fail, e.g. 3-6 of them should fail (yes not 1 failure but several)
and message will appear propably only 1 or 2 times

Please note that on failure the Joomla articles manager will appear sometimes WITHOUT the error message (because multiple "same text" enqueued messages are displayed once and then of course cleaned by the first page view to be able to read them)

It is happening like this:
thread 1 e.g. gets as (existing) editable ids array (31,35)
thread 2 e.g. gets as (existing) editable ids array (31,35)

thread 2 adds 47 and saves array (31,35, 47)
thread 1 adds 58 and saves array (31,35, 58)

Now the editable ids are (31,35, 58) you see that id 47 is missing

Ok we are talking about a different race condition ... yes this is thread drift completely - not addressed by this PR at all.

Im aware of the race condition you are describing. (personally Im not excited to fix that one :) ) - However that is totally to be expected, because Joomla implements a "Checked Out" system that relies on a session containing a lock for the checked out item. The "Checked Out" system is a great feature to stop multiple people editing the same item at the same time. There is simply no good reason for someone to open multiple items in very very quick succession.

Lets not drift this PR's comments further - we need people to test THIS problem and THIS solution - not discuss a different issue and its merits and solutions :)

I confirm that this PR fixes the issues I had observed when opening/editing Users, Articles, Categories, Modules, Plugins, and Templates. ?

From my perspective the issues solved by the PR are significantly more prevalent and disruptive than the race conditions issue.

From my perspective the issues solved by the PR are significantly more prevalent and disruptive than the race conditions issue.

Agreed.

I have tested this item ✅ successfully on c766975

Thats at least 3 (respected) people's tests ok - so hope this will get RTC soon :)

I'll set this to RTC, but more tests are welcome!!!
Thanks @PhilETaylor great stuff

Thanks very much for looking into this issue!

I have tested this item ✅ successfully on c766975

My initial comment was to prevent irrelevant and partly frustrating, useless comments, of someone thinking that it fixes a different issue / case too,
despite the fact that this has been discussed extensively

i never implied something negative of this change, (as long as we test it of course like any PR)
in fact i had asked for these changes in the other PR, i am happy that someone took time to do it

I have tested this item ✅ successfully on c766975

As described in testing instructions this PR solves the 'You are not permitted to use that link' that do appear on second try. After patch you can edit again with no issues seen. Thanks @PhilETaylor nice solution.

@PhilETaylor says:

Im aware of the race condition you are describing. (personally Im not excited to fix that one :) ) - However that is totally to be expected, because Joomla implements a "Checked Out" system that relies on a session containing a lock for the checked out item. The "Checked Out" system is a great feature to stop multiple people editing the same item at the same time. There is simply no good reason for someone to open multiple items in very very quick succession.

The race condition appears to break the "Checked Out" system, allowing the same user session to attempt to open an article twice, hence the error. All of this has been discussed heavily in previous issue threads.

I would like to see a new (or resurrected) tracker issue for this race condition, since the respected commenters here seem to agree it is a real and separate issue. I believe this is what I saw in my SiteGround testing, and randomly sometimes in my own environments, and also reported by others. In previous issue threads, Phil actually went into detail about what would need to be done to actually fix the race condition, and said, in effect, that nobody would ever do it. Is this the consensus now among the respected people, that it's OK to have a race condition pop up occasionally in Joomla, accompanied by what is essentially a meaningless message?

FACT: Look back in the record... I reproduced the race condition WITHOUT the rapid succession testing – i.e. what Phil refers to as "very very quick succession".

@PhilETaylor says:

Personal attacks will not be tolerated either.

... but then he is the first to make personal attacks.

NEWS FLASH: I will not tolerate @PhilETaylor's personal attacks.

To be clear

The "so called race condition" that @durian808 keeps on banging on about is EXACTLY HOW PHP IS DESIGNED TO WORK

PHP cannot be reading the same session data from memory many times quickly and then writing new data to the session in multiple write streams and expect the new data to be merged into some magic session without overwriting data.. thats just not how sessions work.

This PR was NEVER DESIGNED TO FIX PHP SESSION MANAGEMENT

@durian808 is nothing but a troll - read his own words and you will see - accuses me of personal attacks and all I have done is QUOTE HIS OWN WORDS! Facts are Facts.

He would not know a race condition if one hit him in the face. I have tried to educate the poor chap but there is no teaching some people. (although I tried with 2855 words - #9013 (comment))

It is a fact though that this PR fixes @durian808 complaint about editing front end articles in quick succession (#9013 (comment)) - but he has not even bothered testing it, so I'll mention it here to be clear. That WAS NOT a race condition, it was a SiteGround specific issue where MULTIPLE front end servers serve demo sites and SOME had expires enabled and some did not - but again, he never bothered to understand the environment he was testing under, did not bother to contact SiteGround to get the specifics of the service - just used the free demo service as a throw away development tool - not the purpose of the demo service provided by them!

Now it is true that Joomla could improve its checkout process - it could remove the held id from the session completely - but this is out of scope of this PR and is probably a security issue too,

I have no interest in further dialogue about this issue

This PR has RTC and can be merged
(@rdeutz @infograf768 @andrepereiradasilva @zero-24 )

pinging @roland-d FYI (#9035 (comment))

@PhilETaylor says:

The "so called race condition" that @durian808 keeps on banging on about is EXACTLY HOW PHP IS DESIGNED TO WORK

Well, I am not the only one here talking about the race condition, so Phil seems to be attempting a smear campaign. Phil himself even called it a race condition in #9013. This has nothing to do with how PHP is designed to work. It has to do with how "Joomla could improve its checkout process," and "session management," as Phil has explained in previous issue threads, and said nobody would ever fix it, and says "personally Im not excited to fix". Beware of people who make simultaneous contradictory statements.

@durian808 is nothing but a troll - read his own words and you will see - accuses me of personal attacks and all I have done is QUOTE HIS OWN WORDS! Facts are Facts.

I guess @PhilETaylor just doesn't know what a troll is. I guess he just doesn't like me, because I talk about things he would rather not talk about.

He would not know a race condition if one hit him in the face. I have tried to educate the poor chap but there is no teaching some people

I was dealing with race conditions before @PhilETaylor was born.

@durian808 complaint about editing front end articles in quick succession...

No, apparently @PhilETaylor is not actually reading what I write. He also knows that I was able to reproduce the problem without rapid succession testing.

That WAS NOT a race condition, it was a SiteGround specific issue where MULTIPLE front end servers serve demo sites and SOME had expires enabled and some did not...

Oh yeah, then why wasn't anyone else able to reproduce the issue on SiteGround? Nice try.

Some history...

Look at the comments before and after this point in #9013:
https://issues.joomla.org/tracker/joomla-cms/9013#event-125827

@PhilETaylor:

To see this context locking as it should be - open the same article in two tabs, click the edit button on both articles (one in each tab) now save the article in one tab, and you will see that when you save the article in the other tab you REPEATEDLY get the 403 error message as you no longer are holding open the article in a session context. This again is by design and is not a bug.

@durian808:

Why does Joomla need to allow two editing sessions to be open simultaneously for the same user?

@PhilETaylor:

Because its been that way since mambo days... when you open an article to edit it - it is checked out until you save or cancel on it.

@durian808:

[what I am suggesting fixing...] It's the solution to a design problem that has been around since Mambo. The github issue reveals a design shortcoming that causes an annoying UI issue – the root cause is the design shortcoming. ... Why didn't you spot this on your first response to me? Because it took all these exchanges to arrive at this realization? ... Look, man. I don't know your protocol here for what goes where, and frankly, that is beyond me at this point. I have gone way out of my way to help out here. What do we need to do to get this fixed?

@PhilETaylor

I suggest you step away now. If you would like to request major changes and present those to the Production Leadership Team and/or have these added to the Development Strategy and Roadmap then this issue is not the place to do that.

Notice "major changes". This is confirmation from @PhilETaylor that in order to remove the race condition, major changes are needed in Joomla.

@brianteeman or someone, please take action and create (resurrect) an issue item that will cover this race condition case that @PhilETaylor would like to see swept under the rug.

1. I'm not getting involved in this.

2. If you can prove there is still an issue to address pertaining to some race condition with this patch included, then an appropriate issue should be logged. It may very well be that this patch does make whatever issue you or others claim exists an issue that exists in theory only, in which case it really isn't worth my effort (because I am one of a small handful who seem interested or skilled enough to deal with architectural issues) to chase down.

Hopefully this will shed some light on any race condition, if it still exists:

Yes, Joomla allows the same article to be opened for editing twice, by the same user. I have confirmed that Joomla 2.5.28 would produce the 403 error if the same article was opened by the same user in two different browser tabs, and then both edit sessions saved in sequence. The second save would produce the error. (In real-world use, it is conceivable that there could have been a timing issue – or something – in some cases, in some environments, where this error would pop up under normal use.) In Joomla 3.6.5, I cannot get this same behavior to occur – both edit sessions will save successfully without producing the error.

It appears that editing session handling was at some point improved, at least for the case of front-end article editing. I wonder if this can be said for all instances where a resource is "checked out" and then saved. Can anyone identify when this improvement was made?

thanks

I am not sure that @durian808 is aware that Joomla 2.5 is EoL and not
being supported any longer and he cannot reproduce this on J3.6.5 so can
we close this please?

On 1/9/2017 10:35 AM, durian808 wrote:

Hopefully this will shed some light on any race condition, if it still
exists:

Yes, Joomla allows the same article to be opened for editing twice, by
the same user. I have confirmed that Joomla 2.5.28 would produce the
403 error if the same article was opened by the same user in two
different browser tabs, and then both edit sessions saved in sequence.
The second save would produce the error. (In real-world use, it is
conceivable that there could have been a timing issue – or something –
in some cases, in some environments, where this error would pop up
under normal use.) In Joomla 3.6.5, I cannot get this same behavior to
occur – both edit sessions will save successfully without producing
the error.

It appears that editing session handling was at some point improved,
at least for the case of front-end article editing. I wonder if this
can be said for all instances where a resource is "checked out" and
then saved. Can anyone identify when this improvement was made?

thanks

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

Of course I know that Joomla 2.5 is EoL.

I just saw the error while working in the back end of a Joomla 3.6.4 site, during normal use.

I have tested this item ✅ successfully on c766975

I have tested this item ✅ successfully

I'm getting this error also when the cache plugin is on and a I try to directly open a link on the front end from a menu item which has access to registered. Is this related to this one?

@laoneo

I'm getting this error also when the cache plugin is on and a I try to directly open a link on the front end from a menu item which has access to registered. Is this related to this one?

Can you be more specific?

What link are you clicking?

1. the menu item (to show the article)
   If you are not logged in and you try to access a registered item then of course you should be denied access. This is by design.

or

2. the edit button (to edit the article as a logged in registered user)

This PR would fix any caching issues caused by incorrect caching of redirects by browsers for front end article editing (2 above)

@durian808 Please open a new issue for the race condition if you feel it is important. Don't derail this PR which explicitely is not about that.

Also an obvious one: please all stop attacking eachother. It's bad enough this has to be said.

Yes the menu item. I'm logged in with remind me enabled. After a few hours of not browsing the site, when I directly want to open that registered link, it gives me the error.

@laoneo that is a completely different issue then. Please open a new issue and provide full steps to replicate, system information etc.

You might want to seek support on the Forums first - to ensure its not a silly user error rather than a bug in code.

I'm logged in with remind me enabled. After a few hours of not browsing the site, when I directly want to open that registered link, it gives me the error.

@laoneo after all this time do you have any errors logged in the browser's console before hitting the link?

@dgt41 no, it redirects me to the start page.

@PhilETaylor ok, just tough because it is the same error message, probably the caching needs to be disabled on another place as well.

@landor What you are describing is a session expiration issue and is not related to the issue the PR is targeted at in the slightest :)

Don't derail this PR which explicitely is not about that.

I'm not intending to derail anything – just concerned that a possible race condition manifestation of this error may still exist, and didn't want that to be "closed," since the other related issue threads were in fact closed, and it seems that some people still have input that there may be a race condition version of this.

I am done commenting here. If I see this error message again during normal usage, I will definitely open a new issue. Thank you everyone for your work.

@PhilETaylor that's what I thought at beginning as well, but my session hasn't expired. I'm still logged in after the error. But I don't want to pollute this PR anymore. Will set up another issue.

@rdeutz merged commit a6316f0 woohoo! Thanks.

I merge a lot commits, most of the time these are tested and have a RTC state :-)

Thanks Phil,
I assume Joomla will implement this in the next update? I'v got this on all my and clients sites. Annoying.

It's merged, so it will be in Joomla 3.7.0

Apologies if this is a rehash but in case this provides a little more information - - -

We have a clean install of v3.6.5 which we've been working with for a couple of weeks without this issue, and today it appeared. What we are seeing is:

1. As described above this is occurring when clicking on admin links for all Articles but also for the links in Modules and Categories. We haven't seen this happen with menu items.

2. Selecting the checkbox to the left of an Article, Module, or Category and then using the EDIT button doesn't replicate the problem and we can repeatedly access.

3. When we clear ONLY 'cached images and files' in Chrome, it temporarily fixes issue but as described above the second attempt gives us the error. Same with Safari and we haven't tested other browsers.

4. PHP v 5.6.29

   ---

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

Nothing new there @paulcu :) you just confirm the same behaviour that this PR fixes :)

@paulcu please retest when v3.7.0 comes out.

Exactly the same issue over here.

For me the best solution was to moving away from the hoster mijndomein.nl to byte.nl which is one of the best Joomla hosting company in the Netherlands.

So in my opinion it has something to do with the hosting company.

It is nothing to do with the hosting company - it's a simple configuration issue mainly

Sent from my iPhone

On 21 Feb 2017, at 14:40, Lumiga notifications@github.com wrote:

Exactly the same issue over here.

For me the best solution was to moving away from the hoster mijndomein.nl to byte.nl which is one of the best Joomla hosting company in the Netherlands.

So in my opinion it has something to do with the hosting company.

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

Stop promoting your hosting company. This has nothing to do with hosting

This same patch exists here: #12504 and it can be closed now.