Hi, just to clarify, the ResourceProviderDecorator is not a proposal for security - it's a proposal for extensibility. Feature's like the ResourceAccessGate can be implemented with them - but I think the decorator makes sense regardless of that.
While I agree that resource providers should implement access control on their own (or use the one from the underlying storage), I'm not sure if that is feasible or efficient in all cases. If we go down this road, we should add the usage of such a service to all our resource providers (file, servlet, mongo) except jcr. And if we would do this, we would need an additional service which keeps track of all ResourceAccessGate's and has all the logic to handle them implemented and can easily be used by a provider - so basically most of the stuff from Mike which is now in the resource resolver. I'm not against this, but I don't have a strong perference either - so let's hear from Mike what he thinks :) Carsten 2013/3/8 Felix Meschberger <[email protected]>: > Hi all > > There have been a number of threads and proposal flying around recently in an > attempt to make the Resource API more secure: It started with Mike's > ResourceAccessGate and currently is at Carsten's ResourceProviderDecorator. > > I would like to promote a third strategy: > > * ResourceProviders are expected to implement access control at their own > level. They do so in their own implementation or they leverage access control > support of the underlying data store (as the JCR ResourceProvider does). > > * The ResourceAccessGate is a helper service for ResourceProviders to > implement access control if they wish to do so. > > WDYT ? > > Regards > Felix > > -- > Felix Meschberger | Principal Scientist | Adobe > > > > > > > -- Carsten Ziegeler [email protected]
