I've created https://issues.apache.org/jira/browse/SLING-6165 to track this.
On Tue, 4 Oct 2016 at 13:55 Oliver Lietz <apa...@oliverlietz.de> wrote:
> Reviving the discussion around ResourceResolvers for Scripting...
> Radu, Carsten and me had a face-to-face discussion at adaptTo() and we
> that having resource resolvers for scripting like Radu described below is
> 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?
> ---------- Forwarded Message ----------
> Subject: Re: [DISCUSS] new Scripting Service to provide ResourceResolvers
> limited access
> Date: Friday 15 July 2016, 12:02:19
> From: Radu Cotescu <r...@apache.org>
> To: firstname.lastname@example.org
> 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
> 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. */
> * 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. */
> 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):
> 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
> What are your views on this?
> Have a great weekend!
> On Fri, 15 Jul 2016 at 07:57 Carsten Ziegeler <cziege...@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
> > >> 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
> > cziege...@apache.org