I think the discussion here is missunderstood. It's neither about to redefine existing ACLs nor about reinventing something already existing. It's just about introducing hooks or entrypoint to let developers define some other access controlling rules if needed. Sling will NOT have to deal with permissions or policies, users and so on. That's all up to the developer which want's to use the hooks. So if you're are fine with the ACLs from JCR, you don't have to change anything, if you are not, this would give you the chance to solve your problem (like my example to give access to a resource from 8.00 to 17.00). So It would help not only for special rules like the one above, it would also help to handle access controlling on resources which are provided from another resource provider than JCR, like the file system provider, where no access controlling can be attached today. And again: If someone is fine just with the JCR resource provider and the ACLs, nothing will be more complicated after the introduction of the hook than before.
best regards mike > -----Original Message----- > From: Tobias Bocanegra [mailto:[email protected]] > Sent: Wednesday, November 23, 2011 1:04 AM > To: [email protected] > Subject: Re: [RT] Improving access control > > Hi, > I fear the same, that sling tries to re-define and re-implement the > whole JCR API stack (it already does for the most part :-(. Initially > sling was a framework for building web application on top a JCR > repository. But now it's a framework that happens to integrate nicely > on JCR. I think the divergence to JCR started when the resource API > was introduced. Although I like the idea and the elegance of the > 'everything is a resource' approach, it in facts duplicates the JCR > API. > > Keep in mind that when you define any sort of Access Control API for > sling, you eventually need to think about ACLs, Permissions, Policies, > Privileges, Users, Principals, etc... All this is already specified by > JCR or at least available in Jackrabbit. And as alex said: it only > shields you on the resource provider level - but not on the JCR level. > > btw: I'm not sure how far the support for custom policies in > jackrabbit is, but the basics are there. So you can (and should) > implement your 9am-5pm policy definitely on the repository level. > > regards, toby
