at global configuration permissions
and
at Article component
do not assign Edit and Edit.own privilege
(set everything to not-set or "inherited")
Then give edit privelege for a specific article to the manager usergroup via
If a "manager" user logins to backend and tries to edit it, then he will be able to do so
The article manager indeed lists it as editable, but clicking on it , edit is denied
J3.6.1 / J3.6.2
Problem is with new code at allowEdit() method of (backend) article controler
i had made a comment directly on the code about the problem,
Here is my comment
fd72a9f#commitcomment-18521573
Fix is obvious,
and code seemed obviously wrong,
at least fix is easy
Title |
|
Title |
|
Title |
|
Other ACL issue: https://issues.joomla.org/tracker/joomla-cms/11466
Category | ⇒ | ACL Administration Components |
I can confirm the same issue, reported by several users of my extension meanwhile.
The code change in fd72a9f#diff-64d86da3f57caa0ed222b746c070879eR89 caused this issue.
Basically it is checking for JFactory::getUser()->authorise('core.edit', 'com_content);
and directly returning false, without taking the category or article level permissions into account.
Not sure why return parent::allowEdit($data, $key);
was moved from the bottom of the function to the current position.
A simple solution would be to revert to the previous situation with the check at the bottom of the function after checking the article level. But that only works if @wilsonge didn't had a specific reason to move the check?
Labels |
Added:
?
|
The change was in response to a reported and verified security issue so please take into consideration that even though the fix may not be 100% there is not an option to just revert it in full.
Yes tried to guess what exactly they were trying to fix
whatever it was (i have an idea)
it was certainly done the wrong way, since it cancels the way ACL heritage is supposed to work
My guess it was related to https://developer.joomla.org/security-centre/652-20160801-core-core-acl-violations.html
Not sure if there is any other information that can be shared about the security issue? So a proper solution can be found for both the security issue as the bug that is introduced now.
I deleted my comments, i think better focus on a proper fix for next release,
and make a PR that can be tested
I will make a PR soon,
after i testing code thoroughly to fix this B/C break
Hey Both, grab me on my community email (george.wilson (a) community.joomla.org and I'll explain to you the issue that was fixed
Title |
|
||||||
Status | New | ⇒ | Closed | ||||
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-08-07 19:59:59 | ||||
Closed_By | ⇒ | ggppdk |
Status | Closed | ⇒ | New |
Closed_Date | 2016-08-07 20:00:05 | ⇒ | |
Closed_By | ggppdk | ⇒ |
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-08-08 00:46:00 |
Closed_By | ⇒ | ggppdk |
At least this is not a security issue,
Instead it is a usability issue for sites (1% ? or less since we speak about backend) that
Editing for these authors / editors is no longer possible, the new code here needs to be removed,
https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_content/controllers/article.php#L89-L94