Hi, neither admin nor service RRs are put in the stack, only "user" RRs. If you want to update the javadocs, please provide a patch
Thanks Carsten Am 05.06.15 um 09:41 schrieb Jörg Hoh: > 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? > > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
