, 2013 10:05 AM
> To: dev@sling.apache.org
> Subject: Re: Feedback on the current ResourceAccessSecurity API
>
> Hi Mike,
>
> On Wed, Apr 3, 2013 at 9:18 PM, Mike Müller wrote:
> > ...I commited a last shot of the SPI API. The Sling API hasn't changed
> > anymor
Hi Mike,
On Wed, Apr 3, 2013 at 9:18 PM, Mike Müller wrote:
> ...I commited a last shot of the SPI API. The Sling API hasn't changed
> anymore. I think the API is now complete and after all the discussions
> enough mature
I have added/tweaked javadocs on the ResourceAccessSecurity interface
03, 2013 1:48 PM
> To: dev@sling.apache.org
> Subject: Re: Feedback on the current ResourceAccessSecurity API
>
> We discussed this API in length and as I said, the impl is missing. So yes,
> we're not releasing until it's implemented
>
>
> 2013/4/3 Bertrand De
We discussed this API in length and as I said, the impl is missing. So yes,
we're not releasing until it's implemented
2013/4/3 Bertrand Delacretaz
> On Wed, Apr 3, 2013 at 12:17 PM, Carsten Ziegeler
> wrote:
> > ...I would like to cut some releases shortly, especially a new API,
> > resourcer
On Wed, Apr 3, 2013 at 12:17 PM, Carsten Ziegeler wrote:
> ...I would like to cut some releases shortly, especially a new API,
> resourceresolver and jcr resource release...
Do we really want to include Mike's new APIs in a release already?
I'd feel more comfortable if we can look at them in par
applied.
How about the implementation?
Regards
Carsten
2013/3/27 Mike Müller
> +1
>
> > -Original Message-
> > From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> > Sent: Wednesday, March 27, 2013 5:53 PM
> > To: dev@sling.apache.org
> >
+1
> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Wednesday, March 27, 2013 5:53 PM
> To: dev@sling.apache.org
> Subject: Re: Feedback on the current ResourceAccessSecurity API
>
> On Wed, Mar 27, 2013 at 5:48 PM, Cars
On Wed, Mar 27, 2013 at 5:48 PM, Carsten Ziegeler wrote:
> ...What about a neutral name? It's up to the implementation whether it
> optimizes or sanitizes - transformQuery maybe?...
Works for me, suggested javadoc:
**
Allows the ResourceProvider to transform the query based on the
current user's
What about a neutral name? It's up to the implementation whether it
optimizes or sanitizes - transformQuery maybe?
Carsten
2013/3/27 Mike Müller :
>>
>> So it is optimizeQuery really ;-)
>>
>> -Bertrand
>
> optimizeQuery in matters of performant security checks :-)
> Maybe you are right in this c
>
> So it is optimizeQuery really ;-)
>
> -Bertrand
optimizeQuery in matters of performant security checks :-)
Maybe you are right in this case, that we rather should name the method
optimizeQuery than sanitizeQuery.
mike
Hi Mike,
On Wed, Mar 27, 2013 at 12:50 PM, Mike Müller wrote:
> ...It shouldn't scare at all: With or without the use of sanitizeQuery, the
> resulting
> list of resources (or the resulting resource) is checked against security
> anyway...
ok, good then.
> ...The use case is very simple as sh
> > It's not really an optimization in the sense of a QueryOptimizer, that
> > could be
> done
> > by every ResourceProvider by now, without any new API. The sanitizeQuery
> functionality
> > has to come with the ResourceAccessSecurity service: The query can be
> injected
> > (sanitized) only from
Hi Mike,
On Wed, Mar 27, 2013 at 8:54 AM, Mike Müller wrote:
>> > Bertrand wrote:
>> Could sanitizeQuery be done by having the ResourceProvider implement a
>> QueryOptimizer API instead?...
> It's not really an optimization in the sense of a QueryOptimizer, that could
> be done
> by every Resou
> On Mon, Mar 25, 2013 at 8:14 PM, Mike Müller wrote:
> ...
> > Bertrand wrote:
> >> // Calling that canRead would be more consistent with other names
> >> public Resource checkReadPermission( Resource resource );
> >
> > I choosed another naming because canCreate, canDelete, etc. returns
Hi Mike,
Thanks for your replies - as usual I'm a stickler for names...I think
good naming helps a lot in making APIs understandable.
On Mon, Mar 25, 2013 at 8:14 PM, Mike Müller wrote:
...
> Bertrand wrote:
>> // Calling that canRead would be more consistent with other names
>> public R
2013/3/25 Mike Müller :
>> Notes on ResourceAccessSecurity:
>>
>
> At this time ResourceResolver has a method named getUserID() which
> returns a String. The Javadoc of this method says:
> * Get the user ID, if any, associated with this resource resolver. The
> * meaning of this identifie
> Notes on ResourceAccessSecurity:
>
> 1) javadocs says "* - Expected to only be implemented once in the
> framework/application...", I'm not sure about that. If you have both a
> filesystem and an HBase resource providers, they might use very
> different implementations?
>
> 2) Notes as comments
Hi,
See below for a few comments about the recently added ResourceAccessSecurity.
IMO these show that this API will still evolve, which makes me think
that this belongs in the whiteboard for now - maybe using a forked
sling.api bundle if that's easier.
-Bertrand
Notes on ResourceAccessSecurity
18 matches
Mail list logo
