Hi Radu I think your proposed solution is unnecessarily intrusive and complicated. I am still convinced that this issue could be simply and elegantly be solved with a ResourceAccessGate for both servlets and scripts in a generic way.
I think you mean well, but I am under the impression that you slightly misunderstand or lack a deep understanding of Sling's resource tree abstraction and how ResourceAccessGates fit in. Let me explain and you be the judge of whether you misunderstood or not ;) Or indeed if my understanding turns out to be incorrect. Note: I didn't check any camel-cased names to be real class-names and thus blurb is meant to be conceptually correct rather than precise in the details. Sling's resource tree is an aggregate view composed of resources contributed by multiple ResourceProviders. - Most commonly, scripts (e.g. jsp, htl) are stored in a JCR repository and are thus contributed by the JcrResourceProvider. - Servlets are hooked into Sling's resource tree by registering a ServletResourceProvider for each Servlet. - Scripts can be pre-compiled and packaged into bundles as resources exposed by a BundleResourceProvider. IIUC the ResourceAccessGate operates on Slings' resource tree, i.e. the aggregate view. Therefore I would expect it to work seamlessly to deny access to servlets and scripts (servlets are actually handled as scripts with extension "servlet" internally AFAIK). Examples: - DefaultPostServlet, registered at "/libs/sling/servlet/default/POST.servlet", meaning [resourceType=sling/servlet/default, method=POST, script-engine=servlet] - SlingJUnitServlet, registered at "/libs/sling/junit/testing/junit.GET.servlet".,meaning [resourceType=sling/junit/testing, method=GET, extension=junit, script-engine=servlet] - the script /apps/sling/info/info.jsp [resourceType=sling/info, script-engine=jsp] So securing /libs/sling/junit would prevent access to the SlingJUnitServlet, just like securing /apps/sling/info would prevent access to the script /apps/sling/info/info.jsp. There is one possible pitfall that I see: I believe the ScriptResolver uses a service user internally. But maybe we could get our hands on the current request's user and fix this if it is indeed a problem. I hope this helps create a clearer image of what I proposed in the previous thread. Regards Julian On Thu, Oct 4, 2018 at 2:06 PM Radu Cotescu <r...@apache.org> wrote: > > Hi Jason, > > > On 3 Oct 2018, at 22:26, Jason E Bailey <j...@apache.org> wrote: > > > > On Wed, Oct 3, 2018, at 7:57 AM, Radu Cotescu wrote: > > > >> Servlets do create Sling resources, but that’s not applicable to scripts > >> deployed in the search paths. > > > > Could you clarify that a bit for me. I'm under the impression that in Sling > > everything is a resource, when does it not create a resource? > > Sure. A servlet registration, like Justin mentioned on the referenced thread > [0], creates a ResourceProvider mapped to a certain path - just check > /system/console/status-jcrresolver and see the reported paths. Search path > scripts, although at runtime generate Servlets (through adaptation), they > will not generate a similar ResourceProvider like proper Servlets do. > > I guess what I wanted to say is that the behaviour regarding what gets > generated for a resource type mapping is not consistent, hence why trying to > work with what we already have would be difficult, since we’d have to secure > the RP entries (which get created dynamically) and the scripts, but these > resources would be all over the place. > > For now my suggestion is to create an isolated content tree where we’d define > different kinds of permissions, where the sling:resourceType execution would > be one of them. I wouldn’t expose any API for it, just make it an > implementation detail of the Sling Engine. If we figure out we want more > types of permissions we either extend the tree or we start creating an API to > manage everything and maybe even delegate permission storage to other systems. > > Cheers, > Radu
