On 7 March 2013 21:40, Carsten Ziegeler <[email protected]> wrote:
> 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?
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.
eg
/a is managed by a JCR Resource Provider wrapped in a ResourceProviderDecorator
/a/b/c/d/e/f is denied by the ResourceProviderDecorator (eg Timed ACL)
/a/b/c/d/e is allowed by the ResourceProviderDecorator
Node n = resourceResolver.getResource("/a/b/c/d/e").adaptTo(Node.class);
... 20 lines of code ...
Node breach = n.getChild("f");
Replace JCR and Node.class with any storage system that allows child
navigation and a resource.adapto(NodeLikeClass.class).
The only way I can see of making this safe is to block adaptTo on a
resource delivered via this route, and that would be a backwards step.
Sorry.
Ian
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> [email protected]
