Hi, When I just reviewed the latest changes in the API package, I came across SLING-3868.
While it looks good at the first moment and a really useful extension, I have some doubts regarding its usability and security. Assume, I have a request which is handled by some JSP components; these components rely on some background services, which itself deal with ResourceResolvers and might create their own ones (because they need to access parts of the repository, which require different permissions), or re-use the resourceResolver tied to the request (using getThreadResourceResolver()). If the design and the implementation of the application is good, there is no problem. Because the services use only per-call RRs, and and before returning to the callee, any RR opened in this call is closed. But there are applications, where this isn't true; for example services open a ResourceResolver on demand and re-use this session for multiple calls (RR is closed on deactivate of teh service). In such cases the any call to getThreadResourceResolver() will return a wrong resource resolver. This is a pattern which was (is?) quite popular. Can we put a huge disclaimer on the API docs, that special care needs to be taken when using this method? Or even drop the stacking of the RR, so in case of a Request always the RR associated to the the request is returned? I agree, that this behaviour is rare (how often are services activated?), but as it can leak an administrativeRR, the impact can be rather high. WDYT? -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
