Hi, yepp, you're right, only RRs which are retrieved using RRF.getResoureResolver(Map<String,Object>) are pushed to the stack. And JFTR: the stack is required to support impersonation.
Thanks Carsten for answering silly questions :-) Jörg 2015-06-06 3:55 GMT+02:00 Carsten Ziegeler <[email protected]>: > 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 > [email protected] > -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
