403 error - please try to reproduce ... we need feedback!

[jcalvert]

But I have found the problem even on the Joomla demo sites (see my original post).

I'm sure those are just out-of-the box installs w/ no extensions.

JC

[jcalvert]

Goeffrey,

Do you see items staying locked in the back end, even after you save the item?

JC

[GJSchaller]

Let me verify that. I *think* I do, but I usually go to the article through another path on the front end, which then lets me edit it (Search Results, User Article Manager component, etc.).

[jcalvert]

I was working mostly in the back end when I noticed this... editing articles, menus, etc.

thx,
JC

[GJSchaller]

Just reproduced it. When I save it the first time, it saves successfully (I get the System Message stating such). When I then try to re-edit the article from the front end, I get the error, and the article is NOT checked out in the back end.

[jcalvert]

To clarify, my question was "Do you see items staying locked in the back end, even after you save the item?"

In this case, I wasn't suggesting trying to reproduce the 403 error. I was just wondering if you could reproduce erroneous locks (little lock icon) on items in the back end, such as articles and menu links. I.e. by working in the back end – editing and saving articles, modifying menus, etc. – can you reproduce the case of a lock remaining on the item even though it was saved/closed?

thanks,
JC

[GJSchaller]

Ah, I see - I've been working from the font end, the whole time.

Yes, I do see the items locked in the back end, when working from there.

[jcalvert]

To confirm... if you do a global check in, so that nothing is locked, then you start working in the back end (editing articles, saving/closing, editing menus, etc.), then you start to see erroneous persistent locks? I.e. lock icon showing next to an item, even though the item was saved or closed?

thanks,
JC

[GJSchaller]

Correct. I'm getting the "You are not permitted..." #330 message bar, and the item is locked. I just verified it.

This may be different issues, though? One issue lets me open it, but not save... the other won't let me open it to edit at all.

[jcalvert]

Great. One last test please, if you will. Repeat the test, this time don't use the front end at all... just work in the back end (don't even be logged into the front end). Log in as super admin to the back end. Do a global check in, then repeat what you did to reproduce the erroneous lock icon appearing next to items in the back end. Do the locks appear?

thanks,
JC

[GJSchaller]

Clean browser (IE 10) - resets each time it's closed.

Global check-in done.

Opened page, edited, saved. No issues.

Went to re-open it by clicking on the title of the article, got the message "You are not permitted to use that link to directly access that page (#330)."

NO lock on article. Is not listed as checked out in Maintenance: Global Check-In.

Did a Global Check-In anyways, still could not access the article. Was able to access it by selecting it, and clicking on "Edit" instead.

Saved article. Clicked on title, got "You are not permitted to use that link to directly access that page (#330)." again. Still no lock, still cannot open by clicking on title.

I suspect the time I got the lock was a different issue...

[jcalvert]

Hmmm. At this time I'm really curious about the lock issue, not the 303 or 403. When you saw the erroneous lock icon in the back end, were you also logged in to the front end at the same time? Can you reproduce the lock thing somehow? Please try w/ FireFox... that's what I was using when I saw the locks.

thx,
JC

[GJSchaller]

I am usually logged into the front as an Admin, and the back end as a SuperUser.

I am getting repeated (and increasing) reports from users about the issue on the front end - users that cannot log into the back end. This is the main thing that is worrisome to me, as it means Joomla as a whole is rapidly becoming a major issue for us as a solution. If users can't update their documentation on the company's documentation site... that's a big problem.

[jcalvert]

I have a hunch the items erroneously locked in the back end is related to the 403 errors.

My proxy work-around eliminates both these problems.

Now the question is... why?

I will add this new information to the bug tracker.

[GJSchaller]

That makes sense. An article that was throwing the issue this morning is locked in the backend, by someone that does not have back-end access. (She's gone for the day, but I am 90% certain she quit editing the article after the last error she got... I'll try to replicate.)

[GJSchaller]

OK - additional information.

Did a global check-in.

Attempted to replicate in a "clean" (no history, cookies, or cache on load) Firefox - after 10 edit / saves, could not.

Swapped to IE 10, which is also "clean." Received an HTTP 500 error after about 2 edits.

Looked in Back End. Article is NOT locked. Still cannot edit article in IE 10.

Bring Firefox back up. Can edit article fine. Edit & save it several more times without issue.

Go back to IE, which is still open - still cannot edit article. Article is still checked IN in backend.

Am able to edit & save article, from backend, in Chrome, logged in as Super User. Tried editing it twice more, on 2nd Edit got the #330 error on back end. Item is NOT listed as checked out. IE still cannot edit (HTTP 500 error on trying to edit from front end). Can edit and save fine from Firefox on front end.

Going back to the back end, still cannot edit article by clicking on title. If I check off the checkbox, and hit Edit, I can edit the article and save it without issue. The article is NOT showing as checked out in Global Maintenance. Doing a global check-in does not resolve the issue of clicking on the title from the back end.

Closed out IE 10, re-opened it (in a "clean" state). Was able to edit article once. After that, HTTP 500 error again.

Closed tabs in Chrome, but not the browser itself. Re-opened Tabs, was able to edit article in the back end once, then got the #330 again. Closed tabs (but not browser), re-opened, was able to edit the article in the back end yet again, followed by the #330 when clicking on the title again.

This is looking more and more like it's session-based somehow? Closing and re-opening the browser - even just the tab, not the whole browser - seems to clear the issue.

[jcalvert]

I recommend not using IE 10 !! How about retest and only use FireFox. THanks.

[GJSchaller]

Even with IE10 out of the equation, Chrome is showing signs of the issue on the back end. Once I close the tab in Chrome and re-open it, the issue is reset, I can edit the article again without the error again for one or two edits before the #330 comes back up.

I can't reproduce the issue in FF, in the front OR back end, even when logged into both as different users at the same time, from the same instance of FF.

[jcalvert]

I'll set up a demo site that we can test on, Joomla 2.5.14.

[Datatonic]

htaccess with

ExpiresActive On

Causes this error for me. I tried applying Elin's fix here -

http://joomlacode.org/gf/project/joomla ... m_id=29000

But until

ExpiresActive Off

The error is still there.

Could love to know a work around to allow ExpiresActive On but fix the problem.

[mcsmom]

My sense is that there are at least 3 issues (sometimes also the same one in multiple components) that are involved here.
Issues involving checkout I think are separate. You should always be able to edit an article that you yourself have checked out.
Issues involving URL mismatch are the ones that my proposed fix is focused on.

I'm trying to read the whole thing and understand the different pieces.

[GJSchaller]

Breaking them down, I am seeing:

1) An error saving an article, module, or other item in the back end.

2) The inability to click on a link to edit an article, module, or other item in the backend. (This can be bypassed by selecting it, then clicking the Edit button.)

3) The inability to edit an article in the front end.

There may be more, but those are the three I've run into the most. All of them have been resolved by setting ExpiresActive OFF in htaccess for me.

[jcalvert]

Did you have ExpiresActive ON in your .htaccess when you were seeing the errors?

I think the default is ExpiresActive OFF, which is the case with my .htaccess... I still see the error(s) unless I use my proxy workaround.

JC

[GJSchaller]

Yes, it was set to ON in all my .htaccess files. I didn't set it explicitly, but may have configured it somehow without realizing it using a tool.

[blauwhelm]

I'm having problem: 2) The inability to click on a link to edit an article, module, or other item in the backend. (This can be bypassed by selecting it, then clicking the Edit button.)

I've changed ExpiresActive On to Off in my .htacces and now the problem is solved. I use Joomla 3.1.5 with a couple of components. I didn't had the problem with K2 items and also not when cleaning my cache. Also, Firefox didn't give the problem, but Chrome en Ie10 do. But as I said, after changing ExpiresActive On to Off it now works. Still posting, because I prefer to keep caching on via .htaccess...

If you want me to test something, please ask!

[ltempest]

Has anyone found a solution to this, I have tried the htaccess fix above but that is not working. When I try and save an article, module etc or duplicate a module, menu item or content article, I just get a blank white page. Clicking the back button returns me the content / module list with the duplicated item shown.

My client is becoming increasingly frustrated, as am I, that this problem is occurring and seems to be a well known issue on the joomlacode tracker.

Please help!

[DeeMack]

First time posting to the Forums but this issue was/is extremely frustrating and wanted to throw my 2 cents in...

I can 100% confirm the findings in Datatonic's post above from a few weeks ago (Sept.26, 2013):

In my htaccess file I had:

ExpiresActive On = Repeated & Replicable error (You are not permitted to use that link...) in both front and backend

Then changed to:

ExpiresActive Off = Absolutely NO problems - Front *OR* Back end editing... Can repeatedly click on link title in backend and 'Edit' in frontend (using either 'Close' or 'Save & Close') with no errors at all. In backend I tested with articles, menus, modules, plugins, etc. all with no errors!

Only tested so far with IE10, but if it works on that, it will probably work everywhere (LOL).

I also agree with Datanic's sentiments: Having 'ExpiresActive On' can be VERY beneficial for site speed, etc. But until this problem is 100% resolved, the resulting errors are simply unacceptable...

[DeeMack]

Well I've found another (crappy-hacky) work-around for this PITA problem...

I have a site where the users want to edit articles in the front end and this stupid Joomla! error (there, I said it) kept popping up when they edited an article, saved or closed and then tried to edit the same article again.

While the .htaccess fix works for me on all sites I've tested so far (about 12), I really wanted to keep Expiresactive = 'On' to help increase this site's performance.

*NOTE* This is for Joomla! 3.2 - not sure about other versions...

So in frontend/components/com_content/controller.php

Starting on line 72, I changed:

Code: Select all

// Check for edit form.
if ($vName == 'form' && !$this->checkEditId('com_content.edit.article', $id))
{
    // Somehow the person just went to the form - we don't allow that.
    return JError::raiseError(403, JText::sprintf('JLIB_APPLICATION_ERROR_UNHELD_ID', $id));
}

To this:

Code: Select all

// Check for edit form.
if ($vName == 'form' && !$this->checkEditId('com_content.edit.article', $id))
{
    $app = JFactory::getApplication();
    $values = (array) $app->getUserState('com_content.edit.article.id');
    if (!empty($values))
    {
        // Somehow the person just went to the form - we don't allow that.
        return JError::raiseError(403, JText::sprintf('JLIB_APPLICATION_ERROR_UNHELD_ID', $id));
    }
}

This hack will ONLY resolve (repeated) article editing in the front end. ALL other issues people are having will probably still be there

To be perfectly honest, I really don't know if this hack has any security issues so... Use At Your Own Risk! But I'm keeping an eye on things on my site to see if anything fishy goes on.

I totally hate modifying the core code and am pretty sure this cannot be solved using a template over-ride.

I was actually surprised, and saddened, that this was not resolved in the latest 3.2 version, but until it is, we are left to use hacks or sacrificing one thing for another to have a functioning site.

[dorsa]

Analysis Error

The page returned an error: 403 Forbidden

GTmetrix tried to access the page, but your server has denied access to the page. Your server or application may be blocking GTmetrix, or it requires a login. Check the URL and try again.

Please guide me!

[Word Warrior]

This has just started happening on my website. I can edit in the back end but not the front although I can create articles there. Running Joomla v2.5.27 any news on a fix?