2011/11/14 Alexander Klimetschek <aklim...@adobe.com>: > On 13.11.11 22:35, "jsedd...@gmail.com" <jsedd...@gmail.com> wrote: >>ResourceAccessController would be a new concept and interface, which >>allows different implementations as services. A >>ResourceAccessController (presumably again) indicates whether access >>is granted or denied. >> >>The variation I propose is to drop the ACLAwareResourceProvider >>concept and implement a ResourceAccessController for JCR resources >>instead. The implementation would grant or deny access to a resource >>based on ACLs in Jackrabbit. >>... >>I'm not using the term ACL, as the ResourceAccessController are no >>declarative lists of access control information. They can be >>implemented in java, and one possible implementation are ACLs. > > Hmm, doesn't this make ACL evaluation possibly much more difficult? It is > already not always straightforward (although perfectly specified) how > resource based or principal based ACLs inherit, what an effective ACL is > made of etc. Allowing yet another mechanism to basically override the JCR > access control "from the outside" doesn't sound good to me. > This whole idea is not to fix/change ACL handling in JCR, it's about handling this in general in Sling. And I think Julian came up with a general approach which looks tempting - even if this would mean that ACL handling can be made more complicated in the JCR case (but that would be something which a user of Sling would need to implement by himself). This general approach would simplify Sling's architecture and implementation compared to my solution and it would open up for interesting use cases. That said, we haven't decided or implemented anything yet :)
Carsten -- Carsten Ziegeler cziege...@apache.org
