Hi,
Basically, I like the idea of ResourceProviderDecorator to augment and increase
the functionality of a decorated ResourceProvider. But we should not sell it as
a security device, which it is not.
Why not ?
(1) For the reasons explained by Ian: If you adaptTo the resource to the
underlying data (such as File in a "protected" FileSystemResourceProvider) you
get to requested "resources" outside of protection. Right, you leave the save
haven of the Resource API but you get at resources, the
ResourceProviderDecorator would like to protect you from. The only (partial)
help would be for the ResourceProviderDecorator to prevent resources from being
adapted to the underlying data structure and thus know about the decorated
ResourceProviders.
(2) It IMHO violates a simple security principle: Something secure should
prevent access if there is a failure. In the case of a
ResourceProviderDecorator, the failure could be absence of the
ResourceProviderDecorator (a service may be gone at any time). The problem with
such a failure is, that resources become accessible !
So, here's my position: ResourceProviderDecorator yes, but not as a means for
security.
I think security and access protection is something that the ResourceProvider
must take care of and must be aware of. Be it by using a protected data store
(as in the case of the JCR based ResourceProvider) or by implementing
protection in the ResourceProvider itself and being aware of what it means to
implement the adaptTo methods.
I could imagine, that we implement a service, that may be used by security
aware ResourceProviders to query for access control: So the AccessGate proposed
by Mike could in fact be a service to be used by ResourceProviders to implement
access control. The advantage would be that if the AccessGate service is
missing, the ResourceProvider (and its resources) would know and could act
accordingly.
Regards
Felix
Am 07.03.2013 um 11:40 schrieb Carsten Ziegeler:
> 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]
--
Felix Meschberger | Principal Scientist | Adobe
