Closed olaf-otto closed 8 years ago
It's worth knowing that in 6.0 service users are just regular rep:user
authorizables, and configured in the Service User mapping service. As of 6.1 they tightened things up a bit, and now service users can't be just any old user - they have to be a rep:ServiceUser
(new nodetype in 6.1) and while there does appear to be legacy support for the Service User mapping service, there is also a new version of the service which works as a configuration factory rather than a single shared configuration.
I know this is true as at 6.0 SP1 - I'm not sure if any of these changes were included in SP2 or 3 (pretty sure not SP2, less sure about SP3).
Anyway, while the service user concept is a good one, supporting it across multiple AEM versions will probably be tricky. I'm not sure how far back the getServiceResourceResolver
method exists in AEM (e.g 5.6? 5.5?). I think you'd either need to draw a line for 4.0.0 and say only AEM 6.1+, which will limit uptake, or find a way to isolate the functionality into a bundle or something that is conditionally loaded (does Java have #pragma
s?) by AEM version, if that's possible?
Just for future reference, I can only see two instances of getAdministrativeResourceResolver
in the Neba source:
io.neba.core.resourcemodels.registration.ModelRegistryConsolePlugin
(and associated tests)io.neba.core.sling.AdministrativeResourceResolver
(and associated tests)If ModelRegistryConsolePlugin
could make use of the AdministrativeResourceResolver
service, instead of using its own ResourceResolverFactory
that would probably be a good first step to migrating to service resolvers, since everything would be abstracted via that service so there'd be a single point to migrate.
NEBA 4.0.x will support AEM 6.1+ - and this API change is one of the reasons. The others being websocket support and significant differences of the underlying framework revisions as well as support for JAVA 1.8+.
Thus, this change can now leverage the rep:ServiceUser node type and the factory configurations for the service user mapping for deployment.
Update: I've analyzed how Sling addresses this situation. After all, Sling also requires a resource resolver with elevated privileges to access the resource type hierarchy. There (Specifically, in the SlingServletResolver), a service user may be configured, otherwise, the resolution falls back the administrative user.
I think NEBA should follow this style - at the moment I see no benefit in deploying dedicated service users.
While further analyzing the solution option, I discovered the entire usage of the administrative resource resolver can be discarded. With the Sling version shipped with AEM 6.1 (i.e. Sling API 2.9.0), the resource resolver implementation (https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java) features the getParentResourceType method. This method internally switches to the administrative resource resolver.
Thus, NEBA's custom implementation is no longer required. Won't fix.
Up to AEM 6 / Sling 8, services accessing the JCR would often use an administrative resource resolver should they require unrestricted access to all content. Now, a new mechanism to define service users has been introduced (https://cwiki.apache.org/confluence/display/SLING/Service+Authentication). Since using the administrative resource resolver is deprecated, the neba core should switch to the service user API.