Re: [RT] ResourceProviderDecorator

2013-03-13 Thread Angela Schreiber
hi bertrand What I definitely want to keep is the if using JCR, don't use any other access control mechanism constraint, and if people do otherwise it's their problem. no this is not the case. IMHO you are completely mistaken here. if our customers 'do otherwise' (and they usually do for

Re: [RT] ResourceProviderDecorator

2013-03-08 Thread Carsten Ziegeler
2013/3/8 Ian Boston i...@tfd.co.uk: Ok, next stupid question :) How will the ResourceProviderDecorator protect from navigating using a native object of the ResourceProvider impl acquired using an adaptTo ? Another stupid question :) How does a ResourceDecorator prevent such things?

Re: [RT] ResourceProviderDecorator

2013-03-08 Thread Carsten Ziegeler
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

Re: [RT] ResourceProviderDecorator

2013-03-08 Thread Bertrand Delacretaz
On Fri, Mar 8, 2013 at 8:53 AM, Ian Boston i...@tfd.co.uk wrote: ...How will the ResourceProviderDecorator protect from navigating using a native object of the ResourceProvider impl acquired using an adaptTo ?... By native object I assume you mean a JCR Node for example? If yes you're right

Re: [RT] ResourceProviderDecorator

2013-03-08 Thread Ian Boston
On 8 March 2013 19:13, Carsten Ziegeler cziege...@apache.org 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

Re: [RT] ResourceProviderDecorator

2013-03-08 Thread Carsten Ziegeler
2013/3/8 Bertrand Delacretaz bdelacre...@apache.org: What I definitely want to keep is the if using JCR, don't use any other access control mechanism constraint, and if people do otherwise it's their problem. Exactly - that summarizes the whole discussion very good :) You can probably work

Re: [RT] ResourceProviderDecorator

2013-03-08 Thread Carsten Ziegeler
2013/3/8 Ian Boston i...@tfd.co.uk: sources 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 =

Re: [RT] ResourceProviderDecorator

2013-03-08 Thread Ian Boston
On 8 March 2013 19:52, Carsten Ziegeler cziege...@apache.org wrote: 2013/3/8 Ian Boston i...@tfd.co.uk: sources 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)

Re: [RT] ResourceProviderDecorator

2013-03-08 Thread Felix Meschberger
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

[RT] ResourceProviderDecorator

2013-03-07 Thread 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

Re: [RT] ResourceProviderDecorator

2013-03-07 Thread Alexander Klimetschek
On 07.03.2013, at 11:40, Carsten Ziegeler cziege...@apache.org wrote: Decorating a resource provider is not as trivial as decorating a resource because a provider might come in different flavours Wait - I misunderstood your proposal in the other thread. I thought this would still decorate

Re: [RT] ResourceProviderDecorator

2013-03-07 Thread Ian Boston
On 7 March 2013 21:40, Carsten Ziegeler cziege...@apache.org 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

RE: [RT] ResourceProviderDecorator

2013-03-07 Thread Mike Müller
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

Re: [RT] ResourceProviderDecorator

2013-03-07 Thread Carsten Ziegeler
2013/3/7 Carsten Ziegeler cziege...@apache.org: Therefore I propose we add a simple interface: public interface ResourceProviderDecorator { ResourceProvider decorate(final ResourceProvider provider); AttributableResourceProvider decorate(final AttributableResourceProvider

Re: [RT] ResourceProviderDecorator

2013-03-07 Thread Ian Boston
On 8 March 2013 18:27, Mike Müller mike...@mysign.ch 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