Hi Angela,
> custom privilege can either be new aggregates of built-in privileges
> or something really custom. the former is taken into account when
> evaluation permissions for operations being executed on the repository
> (such as read or write). the latter don't have any meaning inside
> jackrabbit and therefore need to be checked and enforced by those
> applications that make use of them.
OK, I thought I am not able to register them at all if they are not aggregates.
That's already valueable.
>
>> - an alternative might be to create new accesscontrol entries that do
>> not only have path restrictions but also nodetype restrictions.
>> However that seems to be quite invasive and a lot of work.
>
> yes... that's true. in addition you would need to evaluate the
> effective node type of the nodes and that's currently quite expensive.
I fear that there is no way around that. But that only applies to
write/delete/modify
scenarios which are relatively rare in my scenario so the performance
hit is most likely acceptable.
>
>> Any other ideas how to tackle that problem?
>
> what do you mean by 'maintain folders' and 'maintain files'?
> what kind of operations does that include?
>
> a common use case i am aware of is that some principals are allowed to
> modify the hierarchy of a tree and others are allowed to edit
> the files in there by manipulating everything below jcr:content.
> that case can usually be covered by path-based restrictions.
That is basically also my use case. The tree is a regional structure like
Europe
| - Suisse
| |...
| - Germany
| - Bavaraia
|-....
Within this structure there are different entities stored. Only a
certain group of users can maintain
the structure of a branch (e.g the germany branch). Maintaining means
create/modify/delete the structure elements.
Another group of users maintains the entities within that structure
but only has read access (add childNodes) to the structure itself
>
> in other words: the different child-item definitions of the file
> vs the folder node type allows to get along with path-based restrictions.
> defining node types with named child item
> definitions will make sure that your content follows your
> naming conventions.
OK, if I got you right then it should look like
Europe
| |-jcr:content
| |-...
|-Suisse
| |-jcr:content
|-Germany
| |-jcr:content
|-Bavaria
| |-jcr:content
| ...
And then the restriction might look like */jcr:content/* if I want to
add/remove rights from the entities.
That is certainly workable however I have an issue with that:
We are using sling where the path is reflected in the URL and a path
like /europe/germany/jcr:content/entity1 looks quite bad.
And as we have three different node types the path would look even
worse: /europe/germany/jcr:content/entity1/jcr:content/subentity
>
> other possibility was to organize your content such that applying
> access control restrictions feels natural...
Unfortunately the hierarchy of regions is fixed so I can not easily
reorganize the content.
Thanks for your input,
Markus
