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 when it
On Wed, Mar 13, 2013 at 10:09 AM, Felix Meschberger fmesc...@adobe.com 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
Hi,
Am 13.03.2013 um 10:18 schrieb Bertrand Delacretaz:
On Wed, Mar 13, 2013 at 10:09 AM, Felix Meschberger fmesc...@adobe.com
wrote:
...Actually: It turns out that doing a ResourceProviderDecorator right is
quite complex given
the potential combinations of ResourceProvider extensions
On Wed, Mar 13, 2013 at 10:38 AM, Felix Meschberger fmesc...@adobe.com 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
On 13.03.2013, at 10:38, Felix Meschberger fmesc...@adobe.com 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
Hi,
Am 13.03.2013 um 12:14 schrieb Alexander Klimetschek:
On 13.03.2013, at 10:38, Felix Meschberger fmesc...@adobe.com 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
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 basic
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
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
.
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 ResourceProviders
Hi,
Should the ResourceAccessGate
Hi,
On Mon, Mar 11, 2013 at 11:36 AM, Mike Müller mike...@mysign.ch 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
[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 ResourceProviders
Hi,
Should the ResourceAccessGate be a service or a utility helper class the
ResourceProvider can instance and configure
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
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
14 matches
Mail list logo
