On 2 Jul 2010, at 10:41, Alexander Klimetschek wrote:
> On Fri, Jul 2, 2010 at 11:29, Bertrand Delacretaz
> <[email protected]> wrote:
>>> Anon, cant list the contents of /_user
>>> /_user/
>>
>> Deny a (custom? new?) "list child nodes" permission on /_user to anon
>
> Currently you would have to deny the jcr:read permission on all child
> nodes to get this effect.
Unfortunately one of the other requirements has been lost in the thread.
/_user/ieb/public/x.pdf
must be readable by anon.
IIIUC, anon jcr:read deny on /_user/ieb will prevent anon from accessing
/_user/ieb/public
and
/_user/ieb/public/x.pdf
since all elements of the path must be readable.
The ACL that is required on /_user is
anon:deny:jcr:list-child-nodes
anon:grant:jcr:read
so that anon can still do
session.getNode("/_user/ieb")
but not
Node n = session.getNodes("/_user");
NodeIterator ni = n.getChildNodes();
I have a feeling this is just not possible in JCR2 at the AccessManager level
since it cant distinguish between a direct request and a listing request, can
you confirm ?
Thanks
Ian
>
> I think this whole situation is best resolved by using principal-based
> access control, which is available in Jackrabbit 2.0 already. It
> stores the permissions via something like path regexps on the user,
> instead of on the resources. The rest would be modeled via groups. You
> can do things like this:
>
> allow = /_user
> deny = /_user/*
>
> To enable it, you have to set this config in the workspace.xml:
>
> <WorkspaceSecurity>
> <AccessControlProvider
> class="org.apache.jackrabbit.core.security.authorization.prinicipalbased.ACLProvider"
> />
> </WorkspaceSecurity>
>
> See the jackrabbit dev list for more information.
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> [email protected]
