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 <r...@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 <cziege...@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 > cziege...@apache.org > > -----------------------------------------
