Combinations of allow/deny rules with actions and repGlob are not fully set

[gruberroland-netcentric]

Example:

• path: /content
  permission: deny
  actions: read,acl_read
  privileges:
  repGlob:
• path: /content
  permission: allow
  actions: read,acl_read
  privileges:
  repGlob: ""
• path: /content
  permission: allow
  actions: read,acl_read
  privileges:
  repGlob: /jcr:*

​I just get the two allow rules. The deny rule is not set.
Probably, this is because when setting the first allow rule without repglob then the deny rule is removed. I saw this kind of effect when I debugged the tool some time ago, OAK seems to remove rules if they are obsoleted by another rule.
Probably, here the second rule with allow removes the first rule since it is added without repglob first (added in a second code step).

[kwin]

The reason for that is that the Security API for setting actions does not support restrictions. Therefore what we do now in the implementation is

1. set the action without the restriction (through the Security API) (that one remove duplicate actions) and then
2. add the restriction on the lastly added action.

In your example the first action and the last action without restrictions are redundant.
As soon as you modify the order, you should not run into that problem.
From an implementation perspective this is not that easy to fix, as the official API does simply not support setting restrictions on actions and reimplementing actions on something we should avoid.

[gruberroland-netcentric]

But if I change the order then the rights are not the same.

[kwin]

Yes, changing the order will change the semantics here. But as a workaround you can split the deny and allow parts into different groups, where one is member of the other. That way the actions are not removed before setting the restrictions.

[seuck]

A similar bug is happening with just these two rules:

- path: /content
  permission: deny
  actions:
  privileges: jcr:all
  repGlob:

- path: /content
  permission: allow
  actions: read
  privileges:
  repGlob: ""

Read privilege will not be included in deny rule.

[kwin]

Another workaround is to use privileges instead of actions.

[albertoalmagro]

Workaround verified. Actions done:

• Move allow permissions to fragment-basic-allow.
• Use privileges instead of actions.

Before:
`

- fragment-basic-allow:

   - path: /
     permission: allow
     actions: read
     privileges: 
     repGlob: 

- fragment-restrict-for-everyone:

   - path: /content
     permission: deny
     actions: read,acl_read
     privileges: 
     repGlob: 

   - path: /content
     permission: allow
     actions: read,acl_read
     privileges: 
     repGlob: ""

   - path: /content
     permission: allow
     actions: read,acl_read
     privileges: 
     repGlob: '/jcr:*'`

After:
`

- fragment-basic-allow:

   - path: /
     permission: allow
     actions: read
     privileges: 
     repGlob: 

   - path: /content
     permission: allow
     actions: 
     privileges: jcr:readAccessControl,jcr:read
     repGlob: ""

   - path: /content
     permission: allow
     actions: 
     privileges: jcr:readAccessControl,jcr:read
     repGlob: '/jcr:*'

- fragment-restrict-for-everyone:

   - path: /content
     permission: deny
     actions: read,acl_read
     privileges: 
     repGlob: `

[gruberroland-netcentric]

Added comment to README that privileges should be used.

[kwin]

I would prefer to keep this issue open and reference this issue in the readme (to provide a littlebit more information around that limitation)

[ghenzler]

Another possible workaround is to use repGlob: "*":

   - path: /content
     permission: deny
     actions: read,acl_read
     privileges: 
     repGlob: "*"

   - path: /content
     permission: allow
     actions: read,acl_read
     privileges: 
     repGlob: ""

   - path: /content
     permission: allow
     actions: read,acl_read
     privileges: 
     repGlob: '/jcr:*'`