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.
I.e. don't restrict the rendered resource (the one that has sling:resourceType=sling/capabilities set), but restrict visibility of the resource that registers the servlet. Of course a nice UI to set this up would be nice. But I think such a solution would be superior to an "ad-hoc" solution that checks an arbitrary resource's permissions (where "arbitrary" may well follow a convention, of course). Regards Julian On Sat, Jun 23, 2018 at 1:28 AM, Eric Norman <[email protected]> wrote: > Honestly, I haven't seen any explanation of the use cases that would > justify the complexity of the solution. > > You seem to be creating a resource in the reposotory whose sole purpose is > to trigger rendering by the servlet bound to the resource type. > > With that in mind, my inclination would be to replace the > capability_resource/renderer_servlet/shadow_acl_node solution with a single > servlet that is mounted at /system/capabilities and remove all the sling > specific semantics from the equation. No resource or shadow resource would > be necessary. > > I would expect that a request that returns a report of registered OSGi > services shouldn't need to know anything else about sling components > running in the same container. > > The rendering and access control could easily be dealt with within the > servlet impl and not require all of the complex administration of the > proposed solution. > > But then again, I may not fully grasp the goals of your use case. > > Regards, > Eric > > On Fri, Jun 22, 2018, 7:06 AM Jason E Bailey <[email protected]> wrote: > >> After looking into it more, I'm kinda surprised that you didn't go with >> the more Sling/ RESTful approach of >> >> $ curl -s -u admin:admin >> http://localhost:8080/org/apache/sling/capabilities.1.json | jq . >> >> { >> "osgi": { >> "framework.bundle.symbolic.name": "org.apache.felix.framework", >> "framework.bundle.version": "5.6.10" >> }, >> "jvm": { >> "java.specification.version": "1.8", >> "java.vm.version": "25.171-b11", >> "java.vm.vendor": "Oracle Corporation" >> } >> } >> >> You could then control access via ACL and just have the resourceType >> report itself rather then everything. >> >> >> - Jason >> >> On Wed, Jun 20, 2018, at 9:38 AM, Bertrand Delacretaz wrote: >> > Hi, >> > >> > I've been working on a (very simple) module to create a "capabilities" >> > endpoint, where a Sling instance can let HTTP clients know about its >> > version levels, presence or absence of certain services etc. >> > >> > It's at >> https://github.com/apache/sling-whiteboard/tree/master/capabilities >> > and if no one is opposed I'll move it to its own module and make a >> > first release later this week. >> > >> > Feedback is welcome. >> > >> > -Bertrand >>
