Re: New "capabilities" module, feedback welcome

Hi Justin, On Wed, Jun 27, 2018 at 9:16 PM Justin Edelson wrote: > ...Looking at this specific case, I'm now thinking that the implementation of > a servlet here is non-idiomatic. It would be better (at least from my > perspective), if this was all handled via ResourceProvider... > ...@Bertrand

Re: New "capabilities" module, feedback welcome

Hi Joerg, Even when a servlet is bound by resource type, it still assigned a resource entry. If you look at /system/console/status-jcrresolver (which is incorrectly named, but that's another story) on a running Sling instance with some servlets installed, you'll see entries for each servlet under

Re: New "capabilities" module, feedback welcome

Hi Julian, the "traditional" way to bind a servlet to the resource tree is to create a resource with the respective resource type. And because in "traditional" setups we most often had backed our resource tree by a JCR repo, so creating a node with the correct resource type property was the way

Re: New "capabilities" module, feedback welcome

E.g. requesting /libs/sling/servlet/default/GET.servlet.tidy.-1.json on a Sling instance returns the following JSON view of the servlet registration resource: { "sling:resourceSuperType": "sling/bundle/resource", "servletClass": "org.apache.sling.servlets.get.impl.DefaultGetServlet",

Re: New "capabilities" module, feedback welcome

Hi Radu Internally, every Servlet registered by resource type in Sling is exposed at one (or several) locations in the Resource tree (!= JCR Node tree). ResourceAccessGate is a pluggable API that allows preventing read access to arbitrary resources. Therefore it is possible to prevent access to

Re: New "capabilities" module, feedback welcome

Hi Julian, > On 26 Jun 2018, at 09:25, Julian Sedding wrote: > > Hi Bertrand > > On Mon, Jun 25, 2018 at 6:22 PM, Bertrand Delacretaz > mailto:bdelacre...@apache.org>> wrote: >> Hi Julian, >> >> On Mon, Jun 25, 2018 at 3:38 PM Julian Sedding wrote: >>> Regarding securing the servlet: >>>

Re: New "capabilities" module, feedback welcome

We partially agree :). 1. Some code needs to find out whether executing an operation called /foo/something/somesubtask is authorized 2. That code calls an authorization service, something like svc.checkPermission(Principal principal, Operation op) 3. That service checks if the operation’s

Re: New "capabilities" module, feedback welcome

Hi Radu, On Wed, Jun 27, 2018 at 12:11 PM Radu Cotescu wrote: > ...I start having the impression that we both proposed the same concept, but > using a > different vocabulary... That's possible - let me describe the execution scenario in my case and see if that matches what you suggest: 1.

Re: New "capabilities" module, feedback welcome

Hi Bertrand, > On 25 Jun 2018, at 18:26, Bertrand Delacretaz wrote: > > On Fri, Jun 22, 2018 at 3:03 PM Radu Cotescu > wrote: >> ...So what we could do is to combine the two ideas: >> >> Have >>/sling/operations >>resourceType1 >>

Re: New "capabilities" module, feedback welcome

Hi Bertrand On Mon, Jun 25, 2018 at 6:22 PM, Bertrand Delacretaz wrote: > Hi Julian, > > On Mon, Jun 25, 2018 at 3:38 PM Julian Sedding wrote: >> Regarding securing the servlet: >> Registering a servlet in Sling creates resources. In the case of the >> capabilities servlet, that should be the

Re: New "capabilities" module, feedback welcome

Hi Radu, On Fri, Jun 22, 2018 at 3:03 PM Radu Cotescu wrote: > ...So what we could do is to combine the two ideas: > > Have > /sling/operations > resourceType1 > ACLs / CUG [0] > resourceType2 > ACLs / CUG

Re: New "capabilities" module, feedback welcome

Hi Julian, On Mon, Jun 25, 2018 at 3:38 PM Julian Sedding 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 >

Re: New "capabilities" module, feedback welcome

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

Re: New "capabilities" module, feedback welcome

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

Re: New "capabilities" module, feedback welcome

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",

Re: New "capabilities" module, feedback welcome

Hi Bertrand, We’ve had an offline discussion a few months back about the possibility of creating an "operations table” in Sling which would allow to whitelist principals that are allowed to execute scripts / servlets bound to certain resource types. IIRC the idea was to have something like:

Re: New "capabilities" module, feedback welcome

Hi Nicolas, On Fri, Jun 22, 2018 at 12:33 AM Nicolas Peltier wrote: > ...Not playing with semantics here, but > don't you see any adherence with sling features?... I think that's orthogonal - features define how a Sling instance is assembled, but once that's done the instance might provide

Re: New "capabilities" module, feedback welcome

On Thu, Jun 21, 2018 at 9:28 PM Jörg Hoh wrote: > ...do you see some usecases in the context of Sling? I understand that in AEM > there are quite some usecases for that, but I wonder why to have that in > Sling. Right now I cannot think of any sling functionality which could be > advertised by

Re: New "capabilities" module, feedback welcome

Hi, Replying to Jörg but I think this addresses Eric's concerns as well. On Thu, Jun 21, 2018 at 9:24 PM Jörg Hoh wrote: > ...this approach of using a shadow permission resource doesn't sound well for > me. I think that binding servlets to a resource type always gives anyone > with write access

Re: New "capabilities" module, feedback welcome

Hi Bertrand! this looks cool and compact indeed! Not playing with semantics here, but don't you see any adherence with sling features? I know those were originally written for initiating an instance, however it's interesting in my opinion to have a "snapshot" of what an instance can do

Re: New "capabilities" module, feedback welcome

One thing I noticed in the example is the (apparent) use of the class name as the namespace. While there doesn't appear to be anything in the API to encourage or require this (if anything the opposite), I'd suggest updating the example to use something that wasn't an implementation detail so that

Re: New "capabilities" module, feedback welcome

Hi Bertrand, 2018-06-20 15:38 GMT+02:00 Bertrand Delacretaz : > 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. > > do you see

Re: New "capabilities" module, feedback welcome

Hi Betrand, 2018-06-21 15:28 GMT+02:00 Bertrand Delacretaz : > > > I think we have discussed a few times how to restrict the execution of > certain servlets like this one, as currently any user who can create a > node with the sling/capabilities resource type can get access to that >

Re: New "capabilities" module, feedback welcome

How do you intend to prevent unauthorizrd users from creating a readable resource with that resource type? Especially with the nt:unstructured data models that are so popular? Maybe I don't fully follow what the general use cases are where a http client would need this information. Is this

Re: New "capabilities" module, feedback welcome

Hi, On Wed, Jun 20, 2018 at 9:47 PM Eugen Stan wrote: > On 20.06.2018 19:02, Eric Norman wrote: > >... It seems to me that there a risk that this endpoint could leave the > >system > > vulnerable to an information disclosure attack. > > > I was thinking the same thing. I think this should be

Re: New "capabilities" module, feedback welcome

Hi Oliver, On Wed, Jun 20, 2018 at 7:48 PM Oliver Lietz wrote: > ...is there no way already to query all available OSGi Capabilities?... That's probably possible but I'm focusing on application-level capabilities here, which might not map directly to OSGi capabilities. For example, an external

Re: New "capabilities" module, feedback welcome

Hi Robert, On Wed, Jun 20, 2018 at 4:09 PM Robert Munteanu wrote: > ...My single note is that the CapabilitiesSource's javadoc says that "(the > capability) name must be unique in a given Sling instance.". I don't > see this enforced or at least checked + logged anywhere Good point! I have

Re: New "capabilities" module, feedback welcome

Hi Jason, On Wed, Jun 20, 2018 at 3:51 PM Jason Bailey wrote: > ...There is an existing VersionInfoServlet in the Default Get servlets > bundle. Would this > module eliminate the need for that service?... Probably - it's easy to provide the same information with the capabilities module. The

Re: New "capabilities" module, feedback welcome

Hi, On Wed, Jun 20, 2018 at 3:38 PM Bertrand Delacretaz wrote: > ...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... As there were no objections (but a few good comments that I'll address next) I have now

Re: New "capabilities" module, feedback welcome

Hi, On 20.06.2018 19:02, Eric Norman wrote: > It seems to me that there a risk that this endpoint could leave the system > vulnerable to an information disclosure attack. > > This is the kind of data that would be useful in refining an attack on the > server. I was thinking the same thing. I

Re: New "capabilities" module, feedback welcome

On Wednesday 20 June 2018 15:38:45 Bertrand Delacretaz wrote: > Hi, Hi Bertrand, > 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. > >

Re: New "capabilities" module, feedback welcome

It seems to me that there a risk that this endpoint could leave the system vulnerable to an information disclosure attack. This is the kind of data that would be useful in refining an attack on the server. Regards, Eric On Wed, Jun 20, 2018, 7:09 AM Robert Munteanu wrote: > Hi Bertrand, > >

Re: New "capabilities" module, feedback welcome

Hi Bertrand, On Wed, 2018-06-20 at 15:38 +0200, 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. > >

RE: New "capabilities" module, feedback welcome

ities" module, feedback welcome EXTERNAL 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/s

New "capabilities" module, feedback welcome

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