[
https://issues.apache.org/jira/browse/SLING-11233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514273#comment-17514273
]
Eric Norman commented on SLING-11233:
-------------------------------------
[~bdelacretaz] The repoinit syntax would not be JSON so a javascript or other
remote client would need extra help to parse it.
This JSON is a more natural fit for alignment with the [content
loading|https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#acls-and-principals-1]
syntax when this change has been proven to be working.
Also, it doesn't seem like repoinit is what this use case is for. The JSON
here is a merged view of all of the (declared or effective) access control
entries. For me, the main use case is for debugging but the same data could
also be used to populate a user interface for viewing/editing an ACL or ACE.
Perhaps we could add a new feature for an ".acl.repoinit" selector that returns
a view of the same information in the repoinit syntax if people would find that
useful. Transforming the JSON object to repoinit syntax should be simple to do.
> Change ACL json structure to be less ambiguous for restrictions
> ---------------------------------------------------------------
>
> Key: SLING-11233
> URL: https://issues.apache.org/jira/browse/SLING-11233
> Project: Sling
> Issue Type: Improvement
> Reporter: Eric Norman
> Assignee: Eric Norman
> Priority: Major
> Fix For: JCR Jackrabbit Access Manager 3.0.12
>
>
> The restriction details in the ACL json can be ambiguous in some situations.
> For example, in the example below it is not clear if the "rep:glob"
> restriction applies to the "jcr:read" privilege or the "rep:write" privilege.
>
> {code:java}
> {
> "user1":{
> "principal":"user1",
> "granted":[
> "jcr:read"
> ],
> "denied":[
> "rep:write"
> ],
> "order":0,
> "restrictions":{
> "rep:glob":"glob1"
> }
> }
> } {code}
>
>
> Expected:
> The JSON structure of the ACE should be enhanced to make it more clear.
> For example, replace the "granted/denied/restrictions" items with a
> "privileges" structure whose items are the granted or denied privileges.
> Each privilege has a "deny" and/or "grant" child whose value is either true
> (no restrictions) or an array of restrictions + values.
> For example:
>
> {code:java}
> {
> "user1":{
> "principal":"user1",
> "order":0,
> "privileges":{
> "jcr:read":{
> "allow":{
> "rep:glob":"glob1"
> }
> },
> "jcr:readAccessControl":{
> "allow":{
> "rep:itemNames":[
> "name1",
> "name2"
> ]
> }
> },
> "rep:write":{
> "deny":true
> }
> }
> }
> } {code}
> The new format should also be flexible enough to describe a privilege that is
> granted and denied with different restrictions for each of those states.
> That scenario is impossible to describe in the old format.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
