search

unic / neba

Lightning fast and simple content mapping for Apache Sling and Adobe AEM
https://neba.io
Apache License 2.0
55 stars 14 forks source link

Replace usages of administrative resource resolver in neba core with service user resource resolvers #99

Closed olaf-otto closed 8 years ago

olaf-otto commented 8 years ago

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.

djessup commented 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 #pragmas?) by AEM version, if that's possible?

djessup commented 8 years ago

Just for future reference, I can only see two instances of getAdministrativeResourceResolver in the Neba source:

  1. io.neba.core.resourcemodels.registration.ModelRegistryConsolePlugin (and associated tests)
  2. 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.

olaf-otto commented 8 years ago

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.

olaf-otto commented 8 years ago

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.

olaf-otto commented 8 years ago

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.