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 <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 > 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 > > > > > ----------------------------------------- >
