Its my understanding that the question on ACL's depends on where it is inheriting the ACL from. Taking your code as literal, you've declared that you own everything under /things and it would inherit the ACL of /. So if you put your ROOT as /content/remote/things You could set JCR ACLs on /content/remote.
Theoretically I assume that your resource could provide an ACL as the ACL is just a resource in the tree. As others suggested using a resource provider in this way may not be the best solution. As the whole point of Sling is to manage content and splitting it into different pieces can be awkward. I'm assuming that you don't need to do POST operations, and that using Oak with an S3 file storage configuration is out. If you can tell Sling what's on the remote store, you could just use a reference to the data. In the same way that in AEM, an image component doesn't necessarily have the image, rather it can have a pointer to the image. So your renderer can just go out and retrieve the image and return it. Or, the Sling Resource Merger https://sling.apache.org/documentation/bundles/resource-merger.html In this case you can merge your resource provider with a JCR Path. So that your resource provider provides the remote content while the associated meta data can be stored in the JCR. Haven't tried this myself though. -- Jason On Fri, Jan 27, 2017, at 04:27 PM, lancedolan wrote: > Hi friends, > > I've tried routing questions through stackoverflow to cut down my mails > to > this list. I'm losing lots of time on this one, though, and am stuck. > > I need to create APIs which don't represent Sling Resources. Example: > /services/images/123123123 > that image will exist somewhere else. > > Bertrand suggests creating a ResourceProvider, as in the example here > [1]. > However, that uses the spi package which is not in version 2.9.0 of > org.apache.sling.api, and thus, not available to me in Sling 8. > > I did find a ResourceProvider interface to implement though, and created > this code: > > /** > * Created by lancedolan on 1/27/17. > */ > @Component > @Service(value=ResourceProvider.class) > @Properties({ > @Property(name = ResourceProvider.ROOTS, value = "things"), > @Property(name = ResourceProvider.OWNS_ROOTS, value = "true") > }) > public class ImageResourceProvider implements ResourceProvider { > > /** If this provider required a context this would be more elaborate, > * but for this simple example we don't need one. > */ > public static class DoesNotNeedAContext { > }; > > @Override > public Resource getResource(ResourceResolver resourceResolver, String > path) { > Resource returnResource = new SyntheticResource(resourceResolver, > path, "edlio/microservice/image"); > returnResource.getValueMap().put("myProp" , "myValue"); > return returnResource; > } > > @Override > public Resource getResource(ResourceResolver resourceResolver, > HttpServletRequest httpServletRequest, String path) { > return getResource(resourceResolver , path); > } > > @Override > public Iterator<Resource> listChildren(Resource resource) { > return null; > } > } > > > The result is that I get a 403 response. How do I control the > authentication > for resources that don't actually exist? The fact that I'm not getting > 404 > means that my ResourceProvider is at least registering successfully. > > Finally, I'd much prefer to use Jersey if possible... Anybody have > success > getting Jersey to work in Sling 8? I dumped a bunch of time into it and > gave > up after class not found errors for classes that should be found [2]. > > The ultimate goal is just to provide a restful API in Sling 8 and the > static-path-declaration of SlingSafeMethodsServlet just doesn't cut it. > > Thanks a million guys... >
