You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Radu Cotescu <ra...@apache.org> on 2016/07/14 13:58:53 UTC
[DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Hi,
In the context of [1] and corroborated by the fact that repoinit was
released, what's your opinion about defining a new service in
o.a.s.scripting.api (implemented in o.a.s.scripting.core) that would
provide ResourceResolvers with restricted access for o.a.s.scripting.*
modules - for starters just one with read-only access to the search paths?
This service could identify the common use cases for ResourceResolver
usages in o.a.s.scripting.* and reduce potential code duplication.
Thanks,
Radu
[1] - https://issues.apache.org/jira/browse/SLING-5254
Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Posted by Carsten Ziegeler <cz...@apache.org>.
> No, the goal is to expose a ResourceResolver backed by the same
> service-user to all scripting modules that need to perform read operations
> on resources from the search paths.
You can share the service user between bundles, I don't understand the
problem to be honest
Carsten
>
> On Thu, 14 Jul 2016 at 16:31 Bertrand Delacretaz <bd...@apache.org>
> wrote:
>
>> But IIUC your goal is only to make some mostly static values available
>> from those services?
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Posted by Radu Cotescu <ra...@cotescu.com>.
No, the goal is to expose a ResourceResolver backed by the same
service-user to all scripting modules that need to perform read operations
on resources from the search paths.
On Thu, 14 Jul 2016 at 16:31 Bertrand Delacretaz <bd...@apache.org>
wrote:
> But IIUC your goal is only to make some mostly static values available
> from those services?
>
Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jul 14, 2016 at 4:13 PM, Radu Cotescu <ra...@cotescu.com> wrote:
>...I was proposing to have a generic service that would be able to
> provide these Resolvers to scripting consumers....
But IIUC your goal is only to make some mostly static values available
from those services?
If that's the case, maybe a set of "environment properties" is more useful?
Leading to something like this in scripts
env.get("sling.search.path")
?
-Bertrand
Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Posted by Radu Cotescu <ra...@cotescu.com>.
Hi Bertrand,
Most of the scripting engines from Sling rely on a ResourceResolver to read
Resources from /libs and /apps. Currently some of them use the
administrative resolver from the ScriptContext attributes and pass that
further wherever they might need it.
Instead of relying on an implementation detail, or creating multiple
service users for Scripting Engines with more or less the same permission
model, I was proposing to have a generic service that would be able to
provide these Resolvers to scripting consumers.
A decent implementation could also make sure that these resolvers are
created efficiently, by storing them lazily in a thread local context per
request and closing them when the request gets destroyed.
Radu
On Thu, 14 Jul 2016 at 16:06 Bertrand Delacretaz <bd...@apache.org>
wrote:
> Hi,
>
> On Thu, Jul 14, 2016 at 3:58 PM, Radu Cotescu <ra...@apache.org> wrote:
> > ...what's your opinion about defining a new service in
> > o.a.s.scripting.api (implemented in o.a.s.scripting.core) that would
> > provide ResourceResolvers with restricted access for o.a.s.scripting.*
> > modules - for starters just one with read-only access to the search
> paths?...
>
> I'm not sure if I understand what you mean, could you give a concrete
> example?
>
> -Bertrand
>
Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Jul 14, 2016 at 3:58 PM, Radu Cotescu <ra...@apache.org> wrote:
> ...what's your opinion about defining a new service in
> o.a.s.scripting.api (implemented in o.a.s.scripting.core) that would
> provide ResourceResolvers with restricted access for o.a.s.scripting.*
> modules - for starters just one with read-only access to the search paths?...
I'm not sure if I understand what you mean, could you give a concrete example?
-Bertrand
Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Posted by Radu Cotescu <ra...@apache.org>.
Ping? :)
On Fri, 15 Jul 2016 at 14:02 Radu Cotescu <ra...@apache.org> wrote:
> 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
>
Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Posted by Radu Cotescu <ra...@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: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Posted by Carsten Ziegeler <cz...@apache.org>.
> 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: [DISCUSS] new Scripting Service to provide ResourceResolvers with limited access
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday 14 July 2016 20:55:26 Carsten Ziegeler wrote:
> > On Thursday 14 July 2016 16:02:46 Carsten Ziegeler wrote:
> >> I think we should have the service user concept and getting a service
> >> user is pretty easy. So I don't see the need for something need,
> >> competing with service users.
> >>
> >> We can discuss about a scripting service user which gets the required
> >> access rights though
> >
> > +1, see my comment in SLING-5252 from yesterday
> >
> > There should be a service user for scripting with limited read access to
> > /apps and /libs (and maybe /etc).
> >
> > I see Radu's point in having a ResourceResolver provider in Scripting
> > Core.
> >
> > All Scripting implementations (everyone!) could ask this provider for a
> > "script reader" ResourceResolver which would call
> > ResourceProviderFactory#getServiceResourceResolver(null) – instead of
> > defining a service user mapping for every scripting implementation.
>
> All that is required is a configuration per bundle and that's it. Do we
> really need an API for that?
No, +1 for scripting service users (subsystems: script reader, cache writer)
and mappings.
> 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.
> 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
Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Posted by Carsten Ziegeler <cz...@apache.org>.
> On Thursday 14 July 2016 16:02:46 Carsten Ziegeler wrote:
>> I think we should have the service user concept and getting a service
>> user is pretty easy. So I don't see the need for something need,
>> competing with service users.
>>
>> We can discuss about a scripting service user which gets the required
>> access rights though
>
> +1, see my comment in SLING-5252 from yesterday
>
> There should be a service user for scripting with limited read access to /apps
> and /libs (and maybe /etc).
>
> I see Radu's point in having a ResourceResolver provider in Scripting Core.
>
> All Scripting implementations (everyone!) could ask this provider for a
> "script reader" ResourceResolver which would call
> ResourceProviderFactory#getServiceResourceResolver(null) \u2013 instead of defining
> a service user mapping for every scripting implementation.
All that is required is a configuration per bundle and that's it. Do we
really need an API for that?
In addition, what if for whatever reason want to use a different service
user for the jsp engine than for the sightly engine?
With the proposal we're tying something together which does not
necessarily belong together just for the sake of saving a single OSGi
configuration.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with limited access
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday 14 July 2016 16:02:46 Carsten Ziegeler wrote:
> I think we should have the service user concept and getting a service
> user is pretty easy. So I don't see the need for something need,
> competing with service users.
>
> We can discuss about a scripting service user which gets the required
> access rights though
+1, see my comment in SLING-5252 from yesterday
There should be a service user for scripting with limited read access to /apps
and /libs (and maybe /etc).
I see Radu's point in having a ResourceResolver provider in Scripting Core.
All Scripting implementations (everyone!) could ask this provider for a
"script reader" ResourceResolver which would call
ResourceProviderFactory#getServiceResourceResolver(null) – instead of defining
a service user mapping for every scripting implementation.
Though it's up to the scripting implementations to close these resolvers.
Regards,
O.
> Carsten
>
> > Hi,
> >
> > In the context of [1] and corroborated by the fact that repoinit was
> > released, what's your opinion about defining a new service in
> > o.a.s.scripting.api (implemented in o.a.s.scripting.core) that would
> > provide ResourceResolvers with restricted access for o.a.s.scripting.*
> > modules - for starters just one with read-only access to the search paths?
> >
> > This service could identify the common use cases for ResourceResolver
> > usages in o.a.s.scripting.* and reduce potential code duplication.
> >
> > Thanks,
> > Radu
> >
> > [1] - https://issues.apache.org/jira/browse/SLING-5254
Re: [DISCUSS] new Scripting Service to provide ResourceResolvers with
limited access
Posted by Carsten Ziegeler <cz...@apache.org>.
I think we should have the service user concept and getting a service
user is pretty easy. So I don't see the need for something need,
competing with service users.
We can discuss about a scripting service user which gets the required
access rights though
Carsten
> Hi,
>
> In the context of [1] and corroborated by the fact that repoinit was
> released, what's your opinion about defining a new service in
> o.a.s.scripting.api (implemented in o.a.s.scripting.core) that would
> provide ResourceResolvers with restricted access for o.a.s.scripting.*
> modules - for starters just one with read-only access to the search paths?
>
> This service could identify the common use cases for ResourceResolver
> usages in o.a.s.scripting.* and reduce potential code duplication.
>
> Thanks,
> Radu
>
> [1] - https://issues.apache.org/jira/browse/SLING-5254
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org