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 <bdelacre...@apache.org> wrote: > Hi, > > On Thu, Jul 14, 2016 at 3:58 PM, Radu Cotescu <r...@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 >
