You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Oliver Lietz <ap...@oliverlietz.de> on 2016/10/04 11:55:42 UTC
Fwd: Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with limited access
Reviving the discussion around ResourceResolvers for Scripting...
Radu, Carsten and me had a face-to-face discussion at adaptTo() and we agree
that having resource resolvers for scripting like Radu described below is the
way to go (for now) to get rid of administrative resolvers.
Any opinions from others on this topic?
Maybe naming ScriptingResourceResolver to ScriptingResourceResolverFactory? Or
adding both methods to ResourceResolverFactory?
Regards,
O.
---------- Forwarded Message ----------
Subject: Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Date: Friday 15 July 2016, 12:02:19
From: Radu Cotescu <ra...@apache.org>
To: dev@sling.apache.org
Hi,
I think I haven't phrased properly my idea so let's give it another shot.
The use cases that I'd like to cover with this service is getting a unified
resource resolver that will be used for:
* resolving script dependencies (data-sly-include / sling:include / other
dependencies like the ones you can define in the Sightly JavaScript Use-API
through the use function, etc.)
* resolving servlets
* resolving scripts that are not request bound (think of workflow
processing engines that support scripts for their steps but that are not
based on HttpServletRequest)
We already have an administrative resource resolver in SlingServletResolver
that for scripting engines gets added into the ScriptContext. ScriptEngines
could rely on it, but passing it down to their own dependency solving
mechanisms might prove tricky, as the ScriptContext provides too much
information and the Bindings are too sensitive for something like this.
Essentially this new service should reside in o.a.s.scripting.api, with an
implementation in o.a.s.scripting.core, so that all o.a.s.scripting
consumers have a single gateway for retrieving scripts, with only one
service user to manage, with a single set of ACLs. For more specific cases
(sub-sets / super-sets of this permissions model) each module should
implement its own access control and reading mechanisms.
I see the service exposing something like:
/**
* Provides a request-scoped ResourceResolver with only read access to the
search paths. This resolver should be used for script resolution in the
context of the same request rendering process. The ResourceResolver should
not be closed by consumers (calling ResourceResolver#close doesn't do
anything), since this service will handle the closing operation
automatically. The ResourceResolver will be shared between scripting
dependencies that render parts of the response for the same request. */
ScriptingResourceResolver#getRequestScopedResourceResolver()
/**
* Provides a ResourceResolver with only read access to the search paths.
Once you're done processing Resource with this ResourceResolver make sure
to close it. */
ScriptingResourceResolver#getResourceResolver()
The implementation is very similar to what the SlingServletResolver does
now with the perThreadResourceResolver, but in the end the
SlingServletResolver will delegate this to the new service, like any other
consumer of the o.a.s.scripting.api.
In Sling I think it's safe to create the service-user like (security
experts are asked to chime in):
[:repoinit]
create path (sling:Folder) /libs
create path (sling:Folder) /apps
create service user sling-scripting
set ACL for sling-scripting
allow jcr:read on /libs,/apps
deny jcr:write on /libs,/apps
end
What are your views on this?
Have a great weekend!
Regards,
Radu
On Fri, 15 Jul 2016 at 07:57 Carsten Ziegeler <cz...@apache.org> wrote:
> > On Thursday 14 July 2016 20:55:26 Carsten Ziegeler wrote:
>
> >
> >> In addition, what if for whatever reason want to use a different service
> >> user for the jsp engine than for the sightly engine?
> >
> > You could still add dedicated service users and ACLs.
>
> But only if the implementation is not using a new api which underneath
> resolves to the same service user :)
>
> Carsten
> >
> >> With the proposal we're tying something together which does not
> >> necessarily belong together just for the sake of saving a single OSGi
> >> configuration.
> >
> > Right. I'm not convinced from that approach either.
> >
> > O.
> >
> >> Carsten
> >
> >
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
>
-----------------------------------------
Re: Re: [DISCUSS] new Scripting Service to provide ResourceResolvers
with limited access
Posted by Radu Cotescu <ra...@apache.org>.
Hi,
I've created https://issues.apache.org/jira/browse/SLING-6165 to track this.
Cheers,
Radu
On Tue, 4 Oct 2016 at 13:55 Oliver Lietz <ap...@oliverlietz.de> wrote:
> Reviving the discussion around ResourceResolvers for Scripting...
>
> Radu, Carsten and me had a face-to-face discussion at adaptTo() and we
> agree
> that having resource resolvers for scripting like Radu described below is
> the
> way to go (for now) to get rid of administrative resolvers.
>
> Any opinions from others on this topic?
>
> Maybe naming ScriptingResourceResolver to
> ScriptingResourceResolverFactory? Or
> adding both methods to ResourceResolverFactory?
>
> Regards,
> O.
>
> ---------- Forwarded Message ----------
>
> Subject: Re: [DISCUSS] new Scripting Service to provide ResourceResolvers
> with
> limited access
> Date: Friday 15 July 2016, 12:02:19
> From: Radu Cotescu <ra...@apache.org>
> To: dev@sling.apache.org
>
> Hi,
>
> I think I haven't phrased properly my idea so let's give it another shot.
>
> The use cases that I'd like to cover with this service is getting a unified
> resource resolver that will be used for:
>
> * resolving script dependencies (data-sly-include / sling:include / other
> dependencies like the ones you can define in the Sightly JavaScript Use-API
> through the use function, etc.)
> * resolving servlets
> * resolving scripts that are not request bound (think of workflow
> processing engines that support scripts for their steps but that are not
> based on HttpServletRequest)
>
> We already have an administrative resource resolver in SlingServletResolver
> that for scripting engines gets added into the ScriptContext. ScriptEngines
> could rely on it, but passing it down to their own dependency solving
> mechanisms might prove tricky, as the ScriptContext provides too much
> information and the Bindings are too sensitive for something like this.
>
> Essentially this new service should reside in o.a.s.scripting.api, with an
> implementation in o.a.s.scripting.core, so that all o.a.s.scripting
> consumers have a single gateway for retrieving scripts, with only one
> service user to manage, with a single set of ACLs. For more specific cases
> (sub-sets / super-sets of this permissions model) each module should
> implement its own access control and reading mechanisms.
>
> I see the service exposing something like:
>
> /**
> * Provides a request-scoped ResourceResolver with only read access to the
> search paths. This resolver should be used for script resolution in the
> context of the same request rendering process. The ResourceResolver should
> not be closed by consumers (calling ResourceResolver#close doesn't do
> anything), since this service will handle the closing operation
> automatically. The ResourceResolver will be shared between scripting
> dependencies that render parts of the response for the same request. */
> ScriptingResourceResolver#getRequestScopedResourceResolver()
>
> /**
> * Provides a ResourceResolver with only read access to the search paths.
> Once you're done processing Resource with this ResourceResolver make sure
> to close it. */
> ScriptingResourceResolver#getResourceResolver()
>
> The implementation is very similar to what the SlingServletResolver does
> now with the perThreadResourceResolver, but in the end the
> SlingServletResolver will delegate this to the new service, like any other
> consumer of the o.a.s.scripting.api.
>
> In Sling I think it's safe to create the service-user like (security
> experts are asked to chime in):
>
> [:repoinit]
> create path (sling:Folder) /libs
> create path (sling:Folder) /apps
> create service user sling-scripting
>
> set ACL for sling-scripting
> allow jcr:read on /libs,/apps
> deny jcr:write on /libs,/apps
> end
>
> What are your views on this?
>
> Have a great weekend!
>
> Regards,
> Radu
>
> On Fri, 15 Jul 2016 at 07:57 Carsten Ziegeler <cz...@apache.org>
> wrote:
>
> > > On Thursday 14 July 2016 20:55:26 Carsten Ziegeler wrote:
> >
> > >
> > >> In addition, what if for whatever reason want to use a different
> service
> > >> user for the jsp engine than for the sightly engine?
> > >
> > > You could still add dedicated service users and ACLs.
> >
> > But only if the implementation is not using a new api which underneath
> > resolves to the same service user :)
> >
> > Carsten
> > >
> > >> With the proposal we're tying something together which does not
> > >> necessarily belong together just for the sake of saving a single OSGi
> > >> configuration.
> > >
> > > Right. I'm not convinced from that approach either.
> > >
> > > O.
> > >
> > >> Carsten
> > >
> > >
> >
> >
> >
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziegeler@apache.org
> >
> >
> -----------------------------------------
>