Ping? :) On Fri, 15 Jul 2016 at 14:02 Radu Cotescu <[email protected]> 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 >
