Hi, looking again at SLING-2708, I think we have a fundamental misconception in the way we treat the resource type hierarchy. This affects the isA check and the detection of the effective resource super type by looking at the resource tree. In early Sling versions we used the current resource resolver (session) in the implementation of those functions, but as soon as the resource resolver did not have read access to the search paths in the resource tree, these checks failed. After hitting this problem, we implemented the isA check by implementing a resource decorator in the Sling Servlet Resolver (SLING-2693). The idea was to use the same user as we use to resolve scripts. With SLING-2708 we hit another area where this problem occurs.
Now, looking back, I think the solution of SLING-2693 is wrong - the resource type hierarchy has nothing to do with execution rights and is completely independent from executing scripts. I think we should rather add two methods to the resource resolver: isA(Resource, String) and getEffectiveSuperType(Resource) - these methods will be implemented by the resource resolver and use a session which has read access to the whole tree (it could also cache the hierarchy if required). With this we have a central implementation at a convenient place. We remove the workaround from the servlet resolver and point all current methods (ResourceUtil and AbstractResource) to the ResourceResolver. WDYT? Carsten -- Carsten Ziegeler [email protected]
