Hi Bertrand On Mon, Jun 25, 2018 at 6:22 PM, Bertrand Delacretaz <[email protected]> wrote: > Hi Julian, > > On Mon, Jun 25, 2018 at 3:38 PM Julian Sedding <[email protected]> wrote: >> Regarding securing the servlet: >> Registering a servlet in Sling creates resources. In the case of the >> capabilities servlet, that should be the resource >> "/libs/sling/capabilities.json.GET.servlet". Since the "Resource >> Access Security" module allows restricting read access to resources, >> this could be used to secure the servlet... > > Yes, but that only works for servlet, I think if we agree on a > (simple) mechanism to secure arbitrary operations, as Radu suggest, > it's more flexible.
Why do you say that only works for servlets? Sling's rendering script resolution is entirely built on topof the resource abstraction. That is the reason that servlets are part of the resource tree in the first place. This in turn leads to the (IMHO desirable) property that "Scripts and Servlets are equal"[0]. [0] https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html#fundamental-scripts-and-servlets-are-equal > > And I'd like this to be backed by Oak so we can take advantage of its > proven access control features, including management tools. Using "Resource Access Security" in order to restrict access to the resource type does not prevent you from implementing a ResourceAccessGate[1] based on (protected) nodes in Oak. The advantages of protecting visibility of the servlet/script that I propose - solves the problem at the root - does not require changes to the servlet/script implementation - because it is entirely orthogonal [1] https://sling.apache.org/documentation/bundles/resource-access-security.html#how-to-implement-resourceaccessgate > > I'll reply to Radu... > > -Bertrand Regards Julian
