You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Eric Norman (Jira)" <ji...@apache.org> on 2020/10/11 23:01:00 UTC
[jira] [Updated] (SLING-9807) AuthorizablePrivilegesInfo is
checking for too may privileges for some of the operations
[ https://issues.apache.org/jira/browse/SLING-9807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Norman updated SLING-9807:
-------------------------------
Description:
canRemove - should require only these privileges:
# jcr:read
# rep:userManagement
canUpdateGroupMembers - should require only these privileges:
# jcr:read
# rep:userManagement
canUpdateProperties - should require only these privileges:
* when adding a new (non-nested) property
## rep:addProperties
* when adding a new nested property
## rep:addProperties
## jcr:addChildNodes
* when altering an existing property
## rep:alterProperties
* when removing a property
## rep:removeProperties
For canRemove and canUpdateGroupMembers this can be solved by reducing the set of privileges it is checking for. For canUpdateProperties, a new variation of that method should be introduced where the user can pass in the types of property updates are expected to be needed.
was:
canRemove - should required only these privileges:
# jcr:read
# rep:userManagement
canUpdateGroupMembers - should require only these privileges:
# jcr:read
# rep:userManagement
canUpdateProperties - should require only these privileges:
* when adding a new (non-nested) property
## rep:addProperties
* when adding a new nested property
## rep:addProperties
## jcr:addChildNodes
* when altering an existing property
## rep:alterProperties
* when removing a property
## rep:removeProperties
For canRemove and canUpdateGroupMembers this can be solved by reducing the set of privileges it is checking for. For canUpdateProperties, a new variation of that method should be introduced where the user can pass in the types of property updates are expected to be needed.
> AuthorizablePrivilegesInfo is checking for too may privileges for some of the operations
> ----------------------------------------------------------------------------------------
>
> Key: SLING-9807
> URL: https://issues.apache.org/jira/browse/SLING-9807
> Project: Sling
> Issue Type: Bug
> Reporter: Eric Norman
> Assignee: Eric Norman
> Priority: Major
> Fix For: JCR Jackrabbit User Manager 2.2.12
>
>
> canRemove - should require only these privileges:
> # jcr:read
> # rep:userManagement
> canUpdateGroupMembers - should require only these privileges:
> # jcr:read
> # rep:userManagement
> canUpdateProperties - should require only these privileges:
> * when adding a new (non-nested) property
> ## rep:addProperties
> * when adding a new nested property
> ## rep:addProperties
> ## jcr:addChildNodes
> * when altering an existing property
> ## rep:alterProperties
> * when removing a property
> ## rep:removeProperties
>
> For canRemove and canUpdateGroupMembers this can be solved by reducing the set of privileges it is checking for. For canUpdateProperties, a new variation of that method should be introduced where the user can pass in the types of property updates are expected to be needed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)