On 7 Jul 2010, at 12:33, Alexander Klimetschek wrote:

> On Wed, Jul 7, 2010 at 09:45, Ian Boston <[email protected]> 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
> [email protected]

Reply via email to