Hi,
Am 13.03.2013 um 12:14 schrieb Alexander Klimetschek:
> On 13.03.2013, at 10:38, Felix Meschberger wrote:
>
>> I think that's start of my thread: Don't use ResourceProviderDecortator or
>> some other non-mandatory thing to implement access control. Access control
>> should be intrinsic to
On 13.03.2013, at 10:38, Felix Meschberger wrote:
> I think that's start of my thread: Don't use ResourceProviderDecortator or
> some other non-mandatory thing to implement access control. Access control
> should be intrinsic to the ResourceProvider and the ResourceProvider should
> either lev
On Wed, Mar 13, 2013 at 10:38 AM, Felix Meschberger wrote:
> Am 13.03.2013 um 10:18 schrieb Bertrand Delacretaz:
>>...adapting the JCR permissions model to Sling
>> resources would be my favorite way by far - that model is known to
>> work and we are familiar with it, no need to reinvent too many
Hi,
Am 13.03.2013 um 10:18 schrieb Bertrand Delacretaz:
> On Wed, Mar 13, 2013 at 10:09 AM, Felix Meschberger
> wrote:
>> ...Actually: It turns out that doing a ResourceProviderDecorator right is
>> quite complex given
>> the potential combinations of ResourceProvider extensions that might hav
On Wed, Mar 13, 2013 at 10:09 AM, Felix Meschberger wrote:
> ...Actually: It turns out that doing a ResourceProviderDecorator right is
> quite complex given
> the potential combinations of ResourceProvider extensions that might have to
> be captured.
> For now I would even go as far as to drop t
Hi,
Am 12.03.2013 um 15:40 schrieb Angela Schreiber:
> hi carsten
>
>> just to clarify, the ResourceProviderDecorator is not a proposal for
>> security - it's a proposal for extensibility.
>
> i tend to disagree. as lars already explained in this thread before
> you can't have extensibility whe
hi carsten
just to clarify, the ResourceProviderDecorator is not a proposal for
security - it's a proposal for extensibility.
i tend to disagree. as lars already explained in this thread before
you can't have extensibility when it comes to access control and
permissions without messing with th
Hi
To be sure (and save some time coding ;-) ), I sum up our discussion:
We can keep the basic singleton service (ResourceAccessSecurity) in the API
and document it like this:
* Expected to only be implemented once in the framework/application
(much like the OSGi LogService or Configurati
> From: Felix Meschberger [mailto:fmesc...@adobe.com]
> > Okay, as far as I understand we've got the consensus of separating my
> > access gate
> > proposal from the Sling API. We should have something like a
> ResourceAccessSecurity
> > service in a extension bundle,
>
> I think we can keep the
d just be
consequential.
Regards
Felix
>
> best regards
> Mike
>
>
>
>> -Original Message-
>> From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian
>> Boston
>> Sent: Friday, March 08, 2013 9:59 PM
>> To: dev@sling.apache.org
Hi,
On Mon, Mar 11, 2013 at 11:36 AM, Mike Müller wrote:
> ...If we go down this road I propose the following:
>
> Making a new bundle (extension) with a new service called
> ResourceAccessSecurity.
> Taking the ResourceAccessGate interface out of the Sling API but keeping it as
> a "access rule
ndleResourceProvider.
WDYT?
best regards
Mike
> -Original Message-
> From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian
> Boston
> Sent: Friday, March 08, 2013 9:59 PM
> To: dev@sling.apache.org
> Subject: Re: [RT] Access Control in R
Hi,
Should the ResourceAccessGate be a service or a utility helper class the
ResourceProvider can instance and configure? I can imagine generalising
path+principal+permission assertions as utility helper class leaving the
ResourceProvider with to implement an interface to provided data to feed
that
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 implem
14 matches
Mail list logo
