On 8 March 2013 18:27, Mike Müller <[email protected]> wrote: >> Sorry for asking a stupid question, but why would a ResourceProvider >> that delivered resources subject to security, not implement it that >> security and cover the use cases required as a part of its >> implementation ? >> >> 1 Allowing insecure ResourceProviders to exist with the intention of >> decorating them feels to be like a dangerous path to take. If they are >> used without decoration they become unsafe. >> >> 2 If the use case is an additional layer of security ontop of a secure >> resource provider (eg a rules based ACL), then I can see that there >> might be a genuine need, but I have to ask why isn't the security part >> of the resource provider itself because its too easy to circumvent >> when resources are navigable. > > > The use case is different: We will (or should) have ResourceProviders for > non ACL aware storages like MongoDB, Cassandra (or like Bertrand > mentioned SolR) etc. in the future. I don't think it would make sense to > implement ACLs or some other security mechanism in each of these > ResourceProviders. And not using them because they do not have a > ACL mechanism is maybe not the right way to go. Sling should not be > only a JCR frontend in the future, that's why I think we should be able to > deal with this new sort of non ACL aware ResourceProviders and at this > point the ResourceProviderDecorator or ResourceAccessGate (or whatever) > comes in. It is not designed to be used as a ACL layer on top of JCR, > there we don't need it.
Ok, next stupid question :) How will the ResourceProviderDecorator protect from navigating using a native object of the ResourceProvider impl acquired using an adaptTo ? Best Regards Ian > > best regards > mike
