You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ie...@tfd.co.uk> on 2010/07/01 13:52:17 UTC
Preventing Listing of child nodes of a resource.
Hi,
I want to be able to stop the listing of all child nodes at specific urls, but still allow direct access to items in a subtree.
Any ideas how this is best done in Sling? (and webdav)
I have lots, but dont know which is going to be best.
eg
Use a ServletFilter to filter all access to /_user
Patch/Configure webdav to only PROPFIND etc /_user/ieb if ieb is the logged in user.
Ian
eg
Anon, cant list the contents of /_user
/_user/
but can list the contents of
/_user/ieb
and can download
/_user/ieb/myinfo.pdf
and ieb can download
/_user/ieb/private/myinfo.pdf
Also
Can webdav upload to
/_user/ieb
but cant see all users at
/_user/
only sees
/_user/ieb
Also
cant see all children of /_user with
/.2.json
RE: Preventing Listing of child nodes of a resource.
Posted by Mike Müller <mi...@mysign.ch>.
> >> 1. In the WebDav area:
> >>
> >> We could modify the webdav servlet to allow other bundles
> to provide an implementation of SlingResourceConfig or
> ItemFilter in the Sling webdav bundle or some other service
> implementation to provide filtering of webdav.
> >
> >
> > It may turn out to be irrelevant, but here is a patch[1] to
> make the WebDav servlet Item Filter pluggable.
> > I have a implementation that works for what I need to do at [2].
> >
> > WDYT about 1 for Sling ?
> > Ian
> >
> >
> >
> > 1 http://codereview.appspot.com/1752041
> > 2
> http://github.com/ieb/open-experiments/blob/master/sandbox/pri
vacy/src/main/java/org/sakaiproject/nakamura/privacy/PrivacyItemFilter.java
>On reflection, the changes I need are quite extensive so I am going to create a custom webdav bundle for Nakamura rather than try and plug all of >these into Slings Webdav bundle. I think our use cases in this area are quire specific.
>
>Ian
To be honest, I'm not sure if your use case is really that specific.
I can imagine that we'll come accross similar problems in the future.
At least should it be possible to get access to a child node if
there are read rights on this node, even if there are no read rights
on one of the parent nodes, which is, as far I followed the discussion,
not possible by the time, because the Sling JCR Resource Provider
follows the nodes down the structure.
best regards
mike
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 6 Jul 2010, at 17:04, Ian Boston wrote:
>
> On 6 Jul 2010, at 09:21, Ian Boston wrote:
>
>>
>> 1. In the WebDav area:
>>
>> We could modify the webdav servlet to allow other bundles to provide an implementation of SlingResourceConfig or ItemFilter in the Sling webdav bundle or some other service implementation to provide filtering of webdav.
>
>
> It may turn out to be irrelevant, but here is a patch[1] to make the WebDav servlet Item Filter pluggable.
> I have a implementation that works for what I need to do at [2].
>
> WDYT about 1 for Sling ?
> Ian
>
>
>
> 1 http://codereview.appspot.com/1752041
> 2 http://github.com/ieb/open-experiments/blob/master/sandbox/privacy/src/main/java/org/sakaiproject/nakamura/privacy/PrivacyItemFilter.java
On reflection, the changes I need are quite extensive so I am going to create a custom webdav bundle for Nakamura rather than try and plug all of these into Slings Webdav bundle. I think our use cases in this area are quire specific.
Ian
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 6 Jul 2010, at 09:21, Ian Boston wrote:
>
> 1. In the WebDav area:
>
> We could modify the webdav servlet to allow other bundles to provide an implementation of SlingResourceConfig or ItemFilter in the Sling webdav bundle or some other service implementation to provide filtering of webdav.
It may turn out to be irrelevant, but here is a patch[1] to make the WebDav servlet Item Filter pluggable.
I have a implementation that works for what I need to do at [2].
WDYT about 1 for Sling ?
Ian
1 http://codereview.appspot.com/1752041
2 http://github.com/ieb/open-experiments/blob/master/sandbox/privacy/src/main/java/org/sakaiproject/nakamura/privacy/PrivacyItemFilter.java
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 7 Jul 2010, at 14:16, Justin Edelson wrote:
> IIUC the number of child nodes isn't relevant. If you broke down the
> children of /users to /users/a, /users/b, /users/c ... /users/z, you
> STILL wouldn't want to allow the children of those nodes to be listed.
Yes thats right, no listing or discovery of the user ids via REST.
Ian
Re: Preventing Listing of child nodes of a resource.
Posted by Justin Edelson <ju...@gmail.com>.
On 7/7/10 8:46 AM, Ian Boston wrote:
>>> Without differentiation between "list child nodes" and "read child node" in jcr-170 or jcr-283, I don't think what I need to be done, can be achieved by any access manager/access control provider that conforms to the standard.
>>>
>>> So I have no option but to put the access control somewhere else.
>>
>> That doesn't solve the IMHO conceptually wrong content model, ie. if
>> the /_user/<userid> node itself is both private and public at the same
>> time.
>>
>>> I will look that the userdir suggestion that Bertrand made, perhaps as a resource resolver as that is probably a better way of doing it in Sling.
>>
>> [1] http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.232:_Drive_the_content_hierarchy.2C_don.27t_let_it_happen.
>
>
> Agreed,
> unfortunately the UX team are in charge of the content hierarchy and they don't agree 100% on that point, the consensus is; millions of child nodes at one point in the hierarchy is Ok, rather like a filesystem with one massive folder. I have tried to convince them of otherwise, but failed.
>
IIUC the number of child nodes isn't relevant. If you broke down the
children of /users to /users/a, /users/b, /users/c ... /users/z, you
STILL wouldn't want to allow the children of those nodes to be listed.
Justin
> Thank you for your help
> Ian
>
>>
>> Regards,
>> Alex
>>
>> --
>> Alexander Klimetschek
>> alexander.klimetschek@day.com
>
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 7 Jul 2010, at 14:25, Alexander Klimetschek wrote:
>> That would allow listing of all the users.
>
> Ah, right, now I am finally getting to the point of this discussion ;-).
Thats probably down to my poor explanation, sorry.
>
> In this case I would give the /content/users node an explicit resource
> type and override all the default get servlets from sling that allow
> listing of that resource in json, xml, webdav etc. to prevent that.
> Which is more or less what was suggest before, I guess :)
Unfortunately /content.2.json gets round that.
Ian
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Wed, Jul 7, 2010 at 14:46, Ian Boston <ie...@tfd.co.uk> wrote:
>> 1) the public part would be some subdirectory of the user node, ie.
>> /_user/<userid>/public_html; then with a principal-based ACL like
>> "read anon /_user/*/public_html" it should be accessible to the
>> public; a special filter would then do the redirect from "~<userid>"
>> URLs to the internal /_user/<userid>/public_html path
>
>
> Unfortunately IIRC the resource resolver in Sling requires read to all the parent nodes back to the root node.
> I will check that again.
Ok, that should be fixed then. If this works in JCR, it should work in
Sling, too. But I am not sure if it really works in JCR... might be
that you need access to all the ancestor nodes there as well. If it
works, then only with the principal-based ACLs, as the resource-based
ACL evaluation stops at a deny on a parent node.
>> 2) separate the user private and public trees completely, ie. for the
>> public part have something like /content /users/<userid>
>
>
> That would allow listing of all the users.
Ah, right, now I am finally getting to the point of this discussion ;-).
In this case I would give the /content/users node an explicit resource
type and override all the default get servlets from sling that allow
listing of that resource in json, xml, webdav etc. to prevent that.
Which is more or less what was suggest before, I guess :)
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 7 Jul 2010, at 12:33, Alexander Klimetschek wrote:
> On Wed, Jul 7, 2010 at 09:45, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>> On 6 Jul 2010, at 22:15, Alexander Klimetschek wrote:
>>
>>> You would not have an anonymous user here at all, as you'd enforce
>>> authentication for the /_user tree.
>>
>>
>> Unfortunately that does not work.
>>
>> /_user/<userid>/**
>>
>> *must* be accessible by anon so we cant force authentication.
>
> What is the use case behind this? Something like "~user" dirs?
Yes
The key bit to remember is that listing all the users is not allowed, I think that is also the case for "~user" dirs
I have a implemented a Sling ResourceProvider that responds to requests at /home and does not list the contents of /home
This appears to work as required and requires no patches to Sling.
I still have to work out how to make webdav usable.
>
> It's a good practice to let the content model follow the access
> control (see also David's model, rule #2 [1]). ~user URLs are in
> conflict with this rule and not sure if they are a good practice
> anyway...
Agreed, however we have users and they have userdirs which are public.
>
> However, I see two solutions:
>
> 1) the public part would be some subdirectory of the user node, ie.
> /_user/<userid>/public_html; then with a principal-based ACL like
> "read anon /_user/*/public_html" it should be accessible to the
> public; a special filter would then do the redirect from "~<userid>"
> URLs to the internal /_user/<userid>/public_html path
Unfortunately IIRC the resource resolver in Sling requires read to all the parent nodes back to the root node.
I will check that again.
>
> 2) separate the user private and public trees completely, ie. for the
> public part have something like /content /users/<userid>
That would allow listing of all the users.
>
>> Without differentiation between "list child nodes" and "read child node" in jcr-170 or jcr-283, I don't think what I need to be done, can be achieved by any access manager/access control provider that conforms to the standard.
>>
>> So I have no option but to put the access control somewhere else.
>
> That doesn't solve the IMHO conceptually wrong content model, ie. if
> the /_user/<userid> node itself is both private and public at the same
> time.
>
>> I will look that the userdir suggestion that Bertrand made, perhaps as a resource resolver as that is probably a better way of doing it in Sling.
>
> [1] http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.232:_Drive_the_content_hierarchy.2C_don.27t_let_it_happen.
Agreed,
unfortunately the UX team are in charge of the content hierarchy and they don't agree 100% on that point, the consensus is; millions of child nodes at one point in the hierarchy is Ok, rather like a filesystem with one massive folder. I have tried to convince them of otherwise, but failed.
Thank you for your help
Ian
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Wed, Jul 7, 2010 at 09:45, Ian Boston <ie...@tfd.co.uk> wrote:
>
> On 6 Jul 2010, at 22:15, Alexander Klimetschek wrote:
>
>> You would not have an anonymous user here at all, as you'd enforce
>> authentication for the /_user tree.
>
>
> Unfortunately that does not work.
>
> /_user/<userid>/**
>
> *must* be accessible by anon so we cant force authentication.
What is the use case behind this? Something like "~user" dirs?
It's a good practice to let the content model follow the access
control (see also David's model, rule #2 [1]). ~user URLs are in
conflict with this rule and not sure if they are a good practice
anyway...
However, I see two solutions:
1) the public part would be some subdirectory of the user node, ie.
/_user/<userid>/public_html; then with a principal-based ACL like
"read anon /_user/*/public_html" it should be accessible to the
public; a special filter would then do the redirect from "~<userid>"
URLs to the internal /_user/<userid>/public_html path
2) separate the user private and public trees completely, ie. for the
public part have something like /content /users/<userid>
> Without differentiation between "list child nodes" and "read child node" in jcr-170 or jcr-283, I don't think what I need to be done, can be achieved by any access manager/access control provider that conforms to the standard.
>
> So I have no option but to put the access control somewhere else.
That doesn't solve the IMHO conceptually wrong content model, ie. if
the /_user/<userid> node itself is both private and public at the same
time.
> I will look that the userdir suggestion that Bertrand made, perhaps as a resource resolver as that is probably a better way of doing it in Sling.
[1] http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.232:_Drive_the_content_hierarchy.2C_don.27t_let_it_happen.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 6 Jul 2010, at 22:15, Alexander Klimetschek wrote:
> You would not have an anonymous user here at all, as you'd enforce
> authentication for the /_user tree.
Unfortunately that does not work.
/_user/<userid>/**
*must* be accessible by anon so we cant force authentication.
Without differentiation between "list child nodes" and "read child node" in jcr-170 or jcr-283, I don't think what I need to be done, can be achieved by any access manager/access control provider that conforms to the standard.
So I have no option but to put the access control somewhere else.
I will look that the userdir suggestion that Bertrand made, perhaps as a resource resolver as that is probably a better way of doing it in Sling.
Thanks for you help.
Ian
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Jul 6, 2010 at 23:06, Ian Boston <ia...@gmail.com> wrote:
> Inline:
>
> Sent from my iPhone
>
> On 6 Jul 2010, at 17:37, Alexander Klimetschek <ak...@day.com> wrote:
>
>> On Tue, Jul 6, 2010 at 17:35, Ian Boston <ie...@tfd.co.uk> wrote:
>>>
>>> Yes, I am not explaining myself clearly. Sorry.
>>>
>>> /_user/aaa is jcr:read anon
>>> ...
>>> /_user/ieb is jcr:read anon
>>> ...
>>> /_user/zzz is jcr:read anon
>>>
>>> but when I do
>>> users.getNodes(); I want to see a list size 0 not a list size n.
>>>
>>> Its the entire list that must be protected.
>>> If I know the ID (aaa,ieb,zzz) I should be able to access it.
>>
>> Then you should login with the ID into the repository, ie. have them
>> as users, because that's what they are.
>
> If i do that, how will i differentiate between anon users and the real user
> who is granted wider access in their own subtree?
>
> Ie /_user/ieb/private is
> denied jcr:read anon
> granted jcr:all ieb
> /_user/ieb/private has a child node subtree
>
> And
> /_user/ieb is
> granted jcr:read anon
> granted jcr:all ieb
> /_user/ieb has a child node subtree
You would not have an anonymous user here at all, as you'd enforce
authentication for the /_user tree.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ia...@gmail.com>.
Inline:
Sent from my iPhone
On 6 Jul 2010, at 17:37, Alexander Klimetschek <ak...@day.com> wrote:
> On Tue, Jul 6, 2010 at 17:35, Ian Boston <ie...@tfd.co.uk> wrote:
>> Yes, I am not explaining myself clearly. Sorry.
>>
>> /_user/aaa is jcr:read anon
>> ...
>> /_user/ieb is jcr:read anon
>> ...
>> /_user/zzz is jcr:read anon
>>
>> but when I do
>> users.getNodes(); I want to see a list size 0 not a list size n.
>>
>> Its the entire list that must be protected.
>> If I know the ID (aaa,ieb,zzz) I should be able to access it.
>
> Then you should login with the ID into the repository, ie. have them
> as users, because that's what they are.
If i do that, how will i differentiate between anon users and the real
user who is granted wider access in their own subtree?
Ie /_user/ieb/private is
denied jcr:read anon
granted jcr:all ieb
/_user/ieb/private has a child node subtree
And
/_user/ieb is
granted jcr:read anon
granted jcr:all ieb
/_user/ieb has a child node subtree
Ian
> Then you can easily set ACLs
> for those paths. Doing this based on anonymous + filter servlets would
> just be another ACL system on top of an existing one.
>
>> If I know every singe ID, I should be able to access every URL, but
>> I should not be able to discover all the IDs from the system.
>>
>> The ID's are Student IDs and under the Data Protection Act as
>> interpreted by the University of Cambridge IDs are not listable by
>> anyone, IIUC this is part of the privacy policy of the University.
>>
>> In the US the regulation is FERPA [1] and its interpretation by
>> the institution.
>>
>> 1 http://en.wikipedia.org/wiki/Family_Educational_Rights_and_Privacy_Act
>
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Jul 6, 2010 at 17:35, Ian Boston <ie...@tfd.co.uk> wrote:
> Yes, I am not explaining myself clearly. Sorry.
>
> /_user/aaa is jcr:read anon
> ...
> /_user/ieb is jcr:read anon
> ...
> /_user/zzz is jcr:read anon
>
> but when I do
> users.getNodes(); I want to see a list size 0 not a list size n.
>
> Its the entire list that must be protected.
> If I know the ID (aaa,ieb,zzz) I should be able to access it.
Then you should login with the ID into the repository, ie. have them
as users, because that's what they are. Then you can easily set ACLs
for those paths. Doing this based on anonymous + filter servlets would
just be another ACL system on top of an existing one.
> If I know every singe ID, I should be able to access every URL, but I should not be able to discover all the IDs from the system.
>
> The ID's are Student IDs and under the Data Protection Act as interpreted by the University of Cambridge IDs are not listable by anyone, IIUC this is part of the privacy policy of the University.
>
> In the US the regulation is FERPA [1] and its interpretation by the institution.
>
> 1 http://en.wikipedia.org/wiki/Family_Educational_Rights_and_Privacy_Act
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 6 Jul 2010, at 16:01, Alexander Klimetschek wrote:
> On Tue, Jul 6, 2010 at 16:42, Ian Boston <ie...@tfd.co.uk> wrote:
>> I understand the principal based ACLs (or at least I think I do). I will have to integrate it into the extension of the Standard ACE/ACE AccessControlProvider since in this workspace we also need the normal ACL and IIRC the repository.xml does not allow you to configure more than one AccessControlProvider per workspace ?
>
> There is a org.apache.jackrabbit.core.security.authorization.combined.CombinedProvider
> that combines both the default resource-based provider
> (org.apache.jackrabbit.core.security.authorization.acl.ACLProvider)
> and the principal-one. Not sure exactly in which order both are
> applied, though. But if you don't mix principal- and resource-based
> ACLs for certain subtrees, it shouldn't be a problem at all.
>
>> I *will* give this a go, however
>> I cant see how this will work when the AccessManager/AccessControlProvider does not discriminate between a listChildNodes call and a getNode call ?
>>
>> IIRC The Sling ResourceResolver impl requires jcr:read to all the elements of a path leading to a node, not just the final node. I remember looking at the resolution process and seeing it walk up path.
>
> As I said above, listing child nodes in getNodes() will check the read
> permission on each child node before including it.
>
> But for your use case it is not even necessary to separate the two
> cases at all, since these are _different_ child nodes, IIUC. The one
> with access is the user's node under /_user/foo, and all the others
> under /_user (expressed by /_user/* in the resource based ACLs) are
> not readable for the user:
>
> Node users = session.getNode("/_user"); // works
> users.getNodes(); // returns only "/_user/foo"
> session.getNode("/_user/foo"); // works, too
> session.getNode("/_user/bar"); // no rights => PathNotFoundException
>
> Or am I missing something in your use case?
Yes, I am not explaining myself clearly. Sorry.
/_user/aaa is jcr:read anon
...
/_user/ieb is jcr:read anon
...
/_user/zzz is jcr:read anon
but when I do
users.getNodes(); I want to see a list size 0 not a list size n.
Its the entire list that must be protected.
If I know the ID (aaa,ieb,zzz) I should be able to access it.
If I know every singe ID, I should be able to access every URL, but I should not be able to discover all the IDs from the system.
The ID's are Student IDs and under the Data Protection Act as interpreted by the University of Cambridge IDs are not listable by anyone, IIUC this is part of the privacy policy of the University.
In the US the regulation is FERPA [1] and its interpretation by the institution.
1 http://en.wikipedia.org/wiki/Family_Educational_Rights_and_Privacy_Act
>
>> Let me do the work and validate is this is the case or not. (after all, I was the one asking the question, so I should be prepared to spend time checking a possible solution :))
>
> Ok, hope it works out as a good solution for you!
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Jul 6, 2010 at 16:42, Ian Boston <ie...@tfd.co.uk> wrote:
> I understand the principal based ACLs (or at least I think I do). I will have to integrate it into the extension of the Standard ACE/ACE AccessControlProvider since in this workspace we also need the normal ACL and IIRC the repository.xml does not allow you to configure more than one AccessControlProvider per workspace ?
There is a org.apache.jackrabbit.core.security.authorization.combined.CombinedProvider
that combines both the default resource-based provider
(org.apache.jackrabbit.core.security.authorization.acl.ACLProvider)
and the principal-one. Not sure exactly in which order both are
applied, though. But if you don't mix principal- and resource-based
ACLs for certain subtrees, it shouldn't be a problem at all.
> I *will* give this a go, however
> I cant see how this will work when the AccessManager/AccessControlProvider does not discriminate between a listChildNodes call and a getNode call ?
>
> IIRC The Sling ResourceResolver impl requires jcr:read to all the elements of a path leading to a node, not just the final node. I remember looking at the resolution process and seeing it walk up path.
As I said above, listing child nodes in getNodes() will check the read
permission on each child node before including it.
But for your use case it is not even necessary to separate the two
cases at all, since these are _different_ child nodes, IIUC. The one
with access is the user's node under /_user/foo, and all the others
under /_user (expressed by /_user/* in the resource based ACLs) are
not readable for the user:
Node users = session.getNode("/_user"); // works
users.getNodes(); // returns only "/_user/foo"
session.getNode("/_user/foo"); // works, too
session.getNode("/_user/bar"); // no rights => PathNotFoundException
Or am I missing something in your use case?
> Let me do the work and validate is this is the case or not. (after all, I was the one asking the question, so I should be prepared to spend time checking a possible solution :))
Ok, hope it works out as a good solution for you!
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 6 Jul 2010, at 13:12, Alexander Klimetschek wrote:
> On Tue, Jul 6, 2010 at 12:53, Ian Boston <ie...@tfd.co.uk> wrote:
>> All users have read to /_user/<userid> becuase there are public materials in /_user/<userid>
>> No users have list on /_user because of the policy.
>
> With principal-based ACLs I think this would look like this, for a user "foo":
>
> Allow read /_user
> Allow read+write /_user/foo
> Deny read /_user/*
>
> The current implementation allows for a base path (/_user) + a glob (*
> in this case). These are the "rep:nodePath" and "rep:glob" properties
> of the rep:ACE node, which must be set as "constraints" using the
> Jackrabbit-specific API [1] (the jcr 2.0 API is completely built
> around resource-based acl storage, thus jackrabbit has to provide some
> extensions to work with principal-based acls).
I understand the principal based ACLs (or at least I think I do). I will have to integrate it into the extension of the Standard ACE/ACE AccessControlProvider since in this workspace we also need the normal ACL and IIRC the repository.xml does not allow you to configure more than one AccessControlProvider per workspace ?
I *will* give this a go, however
I cant see how this will work when the AccessManager/AccessControlProvider does not discriminate between a listChildNodes call and a getNode call ?
IIRC The Sling ResourceResolver impl requires jcr:read to all the elements of a path leading to a node, not just the final node. I remember looking at the resolution process and seeing it walk up path.
Let me do the work and validate is this is the case or not. (after all, I was the one asking the question, so I should be prepared to spend time checking a possible solution :))
Ian
>
> Documentation is a bit scarce, but here are some links:
> http://markmail.org/message/xveqaau6hvunsl6l
> http://jackrabbit.apache.org/api/2.1/org/apache/jackrabbit/api/security/package-summary.html
>
> [1] http://jackrabbit.apache.org/api/2.1/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html#addEntry(java.security.Principal,%20javax.jcr.security.Privilege[],%20boolean,%20java.util.Map)
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Jul 6, 2010 at 12:53, Ian Boston <ie...@tfd.co.uk> wrote:
> All users have read to /_user/<userid> becuase there are public materials in /_user/<userid>
> No users have list on /_user because of the policy.
With principal-based ACLs I think this would look like this, for a user "foo":
Allow read /_user
Allow read+write /_user/foo
Deny read /_user/*
The current implementation allows for a base path (/_user) + a glob (*
in this case). These are the "rep:nodePath" and "rep:glob" properties
of the rep:ACE node, which must be set as "constraints" using the
Jackrabbit-specific API [1] (the jcr 2.0 API is completely built
around resource-based acl storage, thus jackrabbit has to provide some
extensions to work with principal-based acls).
Documentation is a bit scarce, but here are some links:
http://markmail.org/message/xveqaau6hvunsl6l
http://jackrabbit.apache.org/api/2.1/org/apache/jackrabbit/api/security/package-summary.html
[1] http://jackrabbit.apache.org/api/2.1/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.html#addEntry(java.security.Principal,%20javax.jcr.security.Privilege[],%20boolean,%20java.util.Map)
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 6 Jul 2010, at 12:36, Bertrand Delacretaz wrote:
> On Tue, Jul 6, 2010 at 12:53 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>> The data protection policy that is driving this is that, we have 50K users, all with user ID's we have to
>> prevent anyone from getting a list of the user ID's, but still allow someone who knows the user ID to access
>> the content. Its the same as the UserDir module in Apache httpd ie /~ieb
>
> The best might then be to reproduce that using a UserDir servlet?
We could do,
however we need to provide the entire Sling Engine (all methods, selectors, extensions) underneath the url /home/~ieb URL, and the last time I tried to do this with a dynamic virtual path it ended in abject failure as it become impossible to remap and re-dispatch internal requests.
>
> Keep restricted permissions on the real /_user path, and map this
> UserDir servlet to the /home/~* so that it can internally map paths
> like /home/~ieb/foo/bar.pdf to /_user/ieb/foo/bar.pdf while not
> exposing more than needed.
>
> The next problem then is mapping that to WebDAV operations, might be
> more problematic. But IIUC this access is read-only anyway, so just
> HTTP might be sufficient.
Webdav is also a major problem as its the list of user IDs that has to be read only, and PROPFIND on /_user is going to find them.
Permissions look good, however since JCR spec does not discriminate between getNode and listChildNodes from an AccessManager point of view (and IIRC the Sling Resolver does need to be able to read all elements of the path), its a non starter.
I am looking at a plugin mechanism of ItemFilter at the moment.
Ian
>
> -Bertrand
Re: Preventing Listing of child nodes of a resource.
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jul 6, 2010 at 12:53 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>> The data protection policy that is driving this is that, we have 50K users, all with user ID's we have to
> prevent anyone from getting a list of the user ID's, but still allow someone who knows the user ID to access
> the content. Its the same as the UserDir module in Apache httpd ie /~ieb
The best might then be to reproduce that using a UserDir servlet?
Keep restricted permissions on the real /_user path, and map this
UserDir servlet to the /home/~* so that it can internally map paths
like /home/~ieb/foo/bar.pdf to /_user/ieb/foo/bar.pdf while not
exposing more than needed.
The next problem then is mapping that to WebDAV operations, might be
more problematic. But IIUC this access is read-only anyway, so just
HTTP might be sufficient.
-Bertrand
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 6 Jul 2010, at 11:31, Alexander Klimetschek wrote:
> On Tue, Jul 6, 2010 at 12:24, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>
>>
>> On 6 Jul 2010, at 10:15, Alexander Klimetschek wrote:
>>
>>> On Tue, Jul 6, 2010 at 11:13, Alexander Klimetschek <ak...@day.com> wrote:
>>>> On Tue, Jul 6, 2010 at 10:21, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>> A follow up on this, low level permissions wont work since they cant discriminate between list children and get child.
>>>>
>>>> Rereading your original mail now, I note that I didn't see that you
>>>> still want the sub nodes to be accessible. Then my answer is no
>>>> solution, of course ;-)
>>>
>>> Actually principal-based access controls make my suggestion simpler to
>>> setup, especially the second point:
>>
>>
>> We still have the list all children problem here.
>
> No. If userX has read/write access to /_user/ieb but not to /_user/a,
> /_user/b and all the other subnodes of /_user then node.getNodes()
> will only return /_user/ieb.
All users have read to /_user/<userid> becuase there are public materials in /_user/<userid>
No users have list on /_user because of the policy.
Thats what I have to achieve.
Ian
>
>> The data protection policy that is driving this is that, we have 50K users, all with user ID's we have to prevent anyone from getting a list of the user ID's, but still allow someone who knows the user ID to access the content. Its the same as the UserDir module in Apache httpd ie /~ieb
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Jul 6, 2010 at 12:24, Ian Boston <ie...@tfd.co.uk> wrote:
>
>
>
> On 6 Jul 2010, at 10:15, Alexander Klimetschek wrote:
>
>> On Tue, Jul 6, 2010 at 11:13, Alexander Klimetschek <ak...@day.com> wrote:
>>> On Tue, Jul 6, 2010 at 10:21, Ian Boston <ie...@tfd.co.uk> wrote:
>>>> A follow up on this, low level permissions wont work since they cant discriminate between list children and get child.
>>>
>>> Rereading your original mail now, I note that I didn't see that you
>>> still want the sub nodes to be accessible. Then my answer is no
>>> solution, of course ;-)
>>
>> Actually principal-based access controls make my suggestion simpler to
>> setup, especially the second point:
>
>
> We still have the list all children problem here.
No. If userX has read/write access to /_user/ieb but not to /_user/a,
/_user/b and all the other subnodes of /_user then node.getNodes()
will only return /_user/ieb.
> The data protection policy that is driving this is that, we have 50K users, all with user ID's we have to prevent anyone from getting a list of the user ID's, but still allow someone who knows the user ID to access the content. Its the same as the UserDir module in Apache httpd ie /~ieb
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 6 Jul 2010, at 10:15, Alexander Klimetschek wrote:
> On Tue, Jul 6, 2010 at 11:13, Alexander Klimetschek <ak...@day.com> wrote:
>> On Tue, Jul 6, 2010 at 10:21, Ian Boston <ie...@tfd.co.uk> wrote:
>>> A follow up on this, low level permissions wont work since they cant discriminate between list children and get child.
>>
>> Rereading your original mail now, I note that I didn't see that you
>> still want the sub nodes to be accessible. Then my answer is no
>> solution, of course ;-)
>
> Actually principal-based access controls make my suggestion simpler to
> setup, especially the second point:
We still have the list all children problem here.
The data protection policy that is driving this is that, we have 50K users, all with user ID's we have to prevent anyone from getting a list of the user ID's, but still allow someone who knows the user ID to access the content. Its the same as the UserDir module in Apache httpd ie /~ieb
>
>> - /_user and /_user/ieb are readable for anonymous, the other children
>> of /_user are denied
>> - if "ieb" is a user-specific path, you have to authenticate users and
>> work with specific users instead of anonymous
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Jul 6, 2010 at 11:13, Alexander Klimetschek <ak...@day.com> wrote:
> On Tue, Jul 6, 2010 at 10:21, Ian Boston <ie...@tfd.co.uk> wrote:
>> A follow up on this, low level permissions wont work since they cant discriminate between list children and get child.
>
> Rereading your original mail now, I note that I didn't see that you
> still want the sub nodes to be accessible. Then my answer is no
> solution, of course ;-)
Actually principal-based access controls make my suggestion simpler to
setup, especially the second point:
> - /_user and /_user/ieb are readable for anonymous, the other children
> of /_user are denied
> - if "ieb" is a user-specific path, you have to authenticate users and
> work with specific users instead of anonymous
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Jul 6, 2010 at 10:21, Ian Boston <ie...@tfd.co.uk> wrote:
> A follow up on this, low level permissions wont work since they cant discriminate between list children and get child.
Rereading your original mail now, I note that I didn't see that you
still want the sub nodes to be accessible. Then my answer is no
solution, of course ;-)
I don't think it is a good idea to have things "accessible, but not
discoverable". JCR access controls for sure aren't built to support
this case (maybe a custom jackrabbit ACLProvider could be built, but
not sure if it can really differentiate between say parent.getNodes()
and session.getNode()). I don't know of anything out there that does
this separation.
But back to your actual use case:
> eg
> Anon, cant list the contents of /_user
> /_user/
>
> but can list the contents of
> /_user/ieb
>
> and can download
> /_user/ieb/myinfo.pdf
>
> and ieb can download
> /_user/ieb/private/myinfo.pdf
>
> Also
> Can webdav upload to
> /_user/ieb
>
> but cant see all users at
> /_user/
>
> only sees
> /_user/ieb
>
>
> Also
> cant see all children of /_user with
> /.2.json
There are two simple solutions I would see for this use case:
- /_user and /_user/ieb are readable for anonymous, the other children
of /_user are denied
- if "ieb" is a user-specific path, you have to authenticate users and
work with specific users instead of anonymous
> I have done a filter that prevents http access to nodes by a property on that node, its ugly, but works as required, but that leads me to 2 thoughts.
>
> 1. In the WebDav area:
>
> We could modify the webdav servlet to allow other bundles to provide an implementation of SlingResourceConfig or ItemFilter in the Sling webdav bundle or some other service implementation to provide filtering of webdav.
>
> 2. In the default Sling servlet a node property could be used to deny listing of the children of a node.
Just a note: I personally would restrain from building another access
control mechanism into a higher layer (Sling vs. JCR), as it really
complicates the overall system. At least I would object to put
something like this into Sling.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 2 Jul 2010, at 13:00, Ian Boston wrote:
>
> On 2 Jul 2010, at 11:58, Alexander Klimetschek wrote:
>
>>>
>>> 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 ?
>>
>> Conceptually there is no "listing request". When you list sub nodes,
>> you get all nodes that you have access to. Thus there is a single
>> "jcr:read" permission which means access to this node and its
>> properties.
>
>
> Ok, thanks for you help
> Ian
>
A follow up on this, low level permissions wont work since they cant discriminate between list children and get child.
I have done a filter that prevents http access to nodes by a property on that node, its ugly, but works as required, but that leads me to 2 thoughts.
1. In the WebDav area:
We could modify the webdav servlet to allow other bundles to provide an implementation of SlingResourceConfig or ItemFilter in the Sling webdav bundle or some other service implementation to provide filtering of webdav.
2. In the default Sling servlet a node property could be used to deny listing of the children of a node.
WDYT?
Is it worth looking at 2 separate patches or would the be a non starter for Sling ?
Ian
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 2 Jul 2010, at 11:58, Alexander Klimetschek wrote:
>>
>> 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 ?
>
> Conceptually there is no "listing request". When you list sub nodes,
> you get all nodes that you have access to. Thus there is a single
> "jcr:read" permission which means access to this node and its
> properties.
Ok, thanks for you help
Ian
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Jul 2, 2010 at 12:26, Ian Boston <ie...@tfd.co.uk> wrote:
>
> On 2 Jul 2010, at 10:41, Alexander Klimetschek wrote:
>
>> On Fri, Jul 2, 2010 at 11:29, Bertrand Delacretaz
>> <bd...@apache.org> 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.
This should work with the principle-based auth, given a proper order
of the rules, afaik.
> 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 ?
Conceptually there is no "listing request". When you list sub nodes,
you get all nodes that you have access to. Thus there is a single
"jcr:read" permission which means access to this node and its
properties.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 2 Jul 2010, at 10:41, Alexander Klimetschek wrote:
> On Fri, Jul 2, 2010 at 11:29, Bertrand Delacretaz
> <bd...@apache.org> 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
> alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Jul 2, 2010 at 11:29, Bertrand Delacretaz
<bd...@apache.org> 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.
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
alexander.klimetschek@day.com
Re: Preventing Listing of child nodes of a resource.
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Jul 1, 2010 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...I want to be able to stop the listing of all child nodes at specific urls, but still allow direct access to items in a subtree.
> Any ideas how this is best done in Sling? (and webdav)...
I'm fairly ignorant about the internals of access control in
Jackrabbit, so let me go on with a naive "ideal world" idea.
I'll let others find out if that's implementable ;-)
One thing that bugs me in JCR is the lack of the "user owner" and
"group owner" concepts of unix filesystems - I find those very useful
to solve such cases. So my first suggestion would be to introduce
those concept, ideally allowing multiple groups to own a node.
> Anon, cant list the contents of /_user
> /_user/
Deny a (custom? new?) "list child nodes" permission on /_user to anon
>
> but can list the contents of
> /_user/ieb
Session.getNode("/_user/ieb") works because that doesn't require
calling getNodes() on /_user, so "list child nodes" permission not
needed.
>
> and can download
> /_user/ieb/myinfo.pdf
For the same reason
>
> and ieb can download
> /_user/ieb/private/myinfo.pdf
I think you mean "only ieb", in that case I'd set "user owner=ieb" and
"only user owner can read" on /_user/ieb/private
> Can webdav upload to
> /_user/ieb
Yes, because that doesn't require the "list child nodes" permission -
upload must only check for no conflicts with existing nodes (tricky?)
>
> but cant see all users at
> /_user/
because "list child nodes" is denied on /_user/
> only sees
> /_user/ieb
as above
> Also
> cant see all children of /_user with
> /.2.json
because "list child nodes" is denied on /_user/
Dreaming aloud hey?
I often find that's the best way to look for solutions...
-Bertrand
Re: Preventing Listing of child nodes of a resource.
Posted by Justin Edelson <ju...@gmail.com>.
On 7/1/10 9:19 AM, Vidar Ramdal wrote:
> On Thu, Jul 1, 2010 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>> Hi,
>> I want to be able to stop the listing of all child nodes at specific urls, but still allow direct access to items in a subtree.
>> Any ideas how this is best done in Sling? (and webdav)
>>
>> I have lots, but dont know which is going to be best.
>> eg
>> Use a ServletFilter to filter all access to /_user
>> Patch/Configure webdav to only PROPFIND etc /_user/ieb if ieb is the logged in user.
>> [...]
>
> This would be fairly easy to implement using a custom AccessManager.
> But maybe that is not an option.
>
Could you expand on this? AFAIK, AccessManager doesn't know the context
of an access request, which I think is what Ian is describing. Would you
use a ThreadLocal to store the current (Sling)HttpServletRequest?
Re: Preventing Listing of child nodes of a resource.
Posted by Vidar Ramdal <vi...@idium.no>.
>> On Thu, Jul 1, 2010 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>> Hi,
>>> I want to be able to stop the listing of all child nodes at specific urls, but still allow direct access to items in a subtree.
>>> Any ideas how this is best done in Sling? (and webdav)
>>>
>>> I have lots, but dont know which is going to be best.
>>> eg
>>> Use a ServletFilter to filter all access to /_user
>>> Patch/Configure webdav to only PROPFIND etc /_user/ieb if ieb is the logged in user.
>>> [...]
> On 1 Jul 2010, at 14:19, Vidar Ramdal wrote:
>> This would be fairly easy to implement using a custom AccessManager.
>> But maybe that is not an option.
On Thu, Jul 1, 2010 at 5:07 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> That is a good point,
> however doing it at that level will prevent getting child nodes of a node.... which is needed to get the burried public resource
>
> /_user/ieb/public/xyz.pdf
>
> to get that the jcr resolver is going to need to effectively do
> session.getNode("/_user").childNodes()
>
> and the AccessManager wont be able to tell if thats for getting xyz.pdf or to get the child nodes.
>
> ie, at JCR level all the elements of the path have to be resolvable for the target resource to be readable.
Ah, sorry, I misread your original post. So you want to be able to
receive the child resource if you know the address, right?
Then a custom AccessManager won't do. Unless you can deny access to
only the parent node, then I'm pretty sure you won't be able to list
child nodes - but you won't be able to read the parent node either, of
course.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!
Re: Preventing Listing of child nodes of a resource.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 1 Jul 2010, at 14:19, Vidar Ramdal wrote:
> On Thu, Jul 1, 2010 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>> Hi,
>> I want to be able to stop the listing of all child nodes at specific urls, but still allow direct access to items in a subtree.
>> Any ideas how this is best done in Sling? (and webdav)
>>
>> I have lots, but dont know which is going to be best.
>> eg
>> Use a ServletFilter to filter all access to /_user
>> Patch/Configure webdav to only PROPFIND etc /_user/ieb if ieb is the logged in user.
>> [...]
>
> This would be fairly easy to implement using a custom AccessManager.
> But maybe that is not an option.
That is a good point,
however doing it at that level will prevent getting child nodes of a node.... which is needed to get the burried public resource
/_user/ieb/public/xyz.pdf
to get that the jcr resolver is going to need to effectively do
session.getNode("/_user").childNodes()
and the AccessManager wont be able to tell if thats for getting xyz.pdf or to get the child nodes.
ie, at JCR level all the elements of the path have to be resolvable for the target resource to be readable.
Ian
>
> --
> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
> Sommerrogata 13-15, N-0255 Oslo, Norway
> + 47 22 00 84 00 / +47 22 00 84 76
> Quando omni flunkus moritatus!
Re: Preventing Listing of child nodes of a resource.
Posted by Vidar Ramdal <vi...@idium.no>.
On Thu, Jul 1, 2010 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> Hi,
> I want to be able to stop the listing of all child nodes at specific urls, but still allow direct access to items in a subtree.
> Any ideas how this is best done in Sling? (and webdav)
>
> I have lots, but dont know which is going to be best.
> eg
> Use a ServletFilter to filter all access to /_user
> Patch/Configure webdav to only PROPFIND etc /_user/ieb if ieb is the logged in user.
> [...]
This would be fairly easy to implement using a custom AccessManager.
But maybe that is not an option.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!