On 8 March 2013 19:13, Carsten Ziegeler <[email protected]> wrote: > I have another use case for the decorator, it's possible to "enhance" > resources with data coming from a different location, so for example > for the file resource provider I could store metadata about a file > somewhere else and combine the information. This would also support > updating/creating the metadata. > This is also implementable by implementing a new resource provider > which combines the input of two other resource providers, but a > decorator would make this nicer/easier.
That is a valid use case for a decorator pattern as doesn't change or confuse where the responsibility for applying access control lies. I have nothing against the decorator pattern per se, I am just worried that using it to patch ResourceProviders that have no security, with security will be hard to achieve without introducing holes. Obviously, once its introduced it can be used anyway the downstream developer feels fit, but I don't thing we should encourage a pattern that could result in a application that is not intrinsically safe. Sling has a very wide security footprint above the ResourceResolver. The Jackrabbit implementation has protected us from needing to think too deeply about this upto now. Best Regards Ian > > Carsten > > 2013/3/7 Carsten Ziegeler <[email protected]>: >> Hi, >> >> as recent discussion showed, there might be use cases for a resource >> provider decorator. A decorator can be used to add functionality >> across several resource providers. E.g. this would simplify securing >> resource providers which don't support access checks ootb, like the >> file resource provider or the MongoDB resource provider. >> >> Decorating a resource provider is not as trivial as decorating a >> resource because a provider might come in different flavours = >> implement additional functionality through sub interfaces. >> So I think just having a single decorate method is too error-prone as >> the implementation would have to check whether a resource provider >> implements those interfaces and construct a corresponding resource >> provider. >> >> Therefore I propose we add a simple interface: >> public interface ResourceProviderDecorator { >> >> ResourceProvider decorate(final ResourceProvider provider); >> >> AttributableResourceProvider decorate(final >> AttributableResourceProvider provider); >> >> ModifyingResourceProvider decorate(final ModifyingResourceProvider >> provider); >> >> QueriableResourceProvider decorate(final QueriableResourceProvider >> provider); >> >> DynamicResourceProvider decorate(final DynamicResourceProvider provider); >> } >> >> which allows to decorate each separately. At the same time we add >> wrapper implementations for all of the above which delegate to the >> passed in resource provider. This makes the implementation much >> easier. >> >> The decorators are ordered by their service ranking and called in this order. >> >> WDYT? >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> [email protected] > > > > -- > Carsten Ziegeler > [email protected]
