2011/11/22 Vidar Ramdal <[email protected]>: > 2011/11/22 Carsten Ziegeler <[email protected]>: >> This idea is about to provide a general approach for resource >> checking. Noone prevents you from doing a virtual tree in the jcr >> repository to check access of resources provided by other providers. >> But that's an implementation detail which I don't want to require >> upfront! > > I'm coming late to this party, but having read the thread I'm not sure > if the proposal is about a) specifying access control APIs to be > implemented by resource providers, or b) implement access control > logic independently from (on top of) resource providers. > Can someone clarify? > > With b), it would be easy to re-use access control logic across > resource providers (like the 9:00-17:00 rule), but I suspect it will > introduce other problems, such as with Jackrabbit's Lucene search > results - you don't want to return a search result that the user don't > have access to. > > With a), we simply delegate all access control to resource providers > (like JCR), which will pretend a resource does not exist if the user > has no access to it. But then, what will be the point of having Sling > APIs for access control? In other words, why does Sling need to know > that a resource exists, when it is unaccessible for the user? > Hi,
the idea is about b) - I agree that thinks like search might get a little bit...well...interesting :) Though if you use the Sling search, you get resources and they will go through the same check mechanism. Sure, we could go with a) but this would require to forsee such checks in each and every resource provider and accordingly configure it for each provider. This is something I wanted to avoid. Use cases like Mike's sound to fit perfectly into b). Regards Carsten -- Carsten Ziegeler [email protected]
