You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2013/04/03 12:17:03 UTC
Re: Feedback on the current ResourceAccessSecurity API
Hi,
I would like to cut some releases shortly, especially a new API,
resourceresolver and jcr resource release.
I think, this is the only item blocking this. From the api pov, I guess
only the definition of the resource provider property is missing which
controls whether the RAS should be applied.
How about the implementation?
Regards
Carsten
2013/3/27 Mike Müller <mi...@mysign.ch>
> +1
>
> > -----Original Message-----
> > From: Bertrand Delacretaz [mailto:bdelacretaz@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, Carsten Ziegeler <cz...@apache.org>
> > 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 credentials. Can be used to narrow down queries to omit
> > results that the current user is not allowed to see anyway, speeding
> > up downstream access control.
> >
> > Query transformations are not critical w.r.t access control as results
> > are checked using the canRead.. methods anyway.
> > ***
> >
> > -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
RE: Feedback on the current ResourceAccessSecurity API
Posted by Mike Müller <mi...@mysign.ch>.
Thank you Bertrand for the more precise javadocs. I have also
changed to javadoc from AccessSecurityException to be more
generic. (commited in r1464476)
best regards
Mike
> -----Original Message-----
> From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
> Sent: Thursday, April 04, 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 <mi...@mysign.ch> 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
> in revision 1464342, could you cross-check?
>
> Also, the AccessSecurityException javadoc says "Exception thrown by
> ResourceAccessGate#sanitizeQuery(String, String,
> org.apache.sling.auth.core.spi.AuthenticationInfo) if the query is not
> allowed or illegal.", I would move that info to the sanitizeQuery
> method instead, and make the exception description more generic - feel
> free to do that if you agree.
>
> -Bertrand
Re: Feedback on the current ResourceAccessSecurity API
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Mike,
On Wed, Apr 3, 2013 at 9:18 PM, Mike Müller <mi...@mysign.ch> 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
in revision 1464342, could you cross-check?
Also, the AccessSecurityException javadoc says "Exception thrown by
ResourceAccessGate#sanitizeQuery(String, String,
org.apache.sling.auth.core.spi.AuthenticationInfo) if the query is not
allowed or illegal.", I would move that info to the sanitizeQuery
method instead, and make the exception description more generic - feel
free to do that if you agree.
-Bertrand
RE: Feedback on the current ResourceAccessSecurity API
Posted by Mike Müller <mi...@mysign.ch>.
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.
best regards
mike
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: Wednesday, April 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 Delacretaz <bd...@apache.org>
>
> > On Wed, Apr 3, 2013 at 12:17 PM, Carsten Ziegeler <cz...@apache.org>
> > 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 parallel, and
> > release only once we have at least a basic implementation that
> > demonstrates the ideas.
> >
> > -Bertrand
> >
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Feedback on the current ResourceAccessSecurity API
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <bd...@apache.org>
> On Wed, Apr 3, 2013 at 12:17 PM, Carsten Ziegeler <cz...@apache.org>
> 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 parallel, and
> release only once we have at least a basic implementation that
> demonstrates the ideas.
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Feedback on the current ResourceAccessSecurity API
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Apr 3, 2013 at 12:17 PM, Carsten Ziegeler <cz...@apache.org> 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 parallel, and
release only once we have at least a basic implementation that
demonstrates the ideas.
-Bertrand