2012/6/13 Bertrand Delacretaz <[email protected]>: > On Jun 10, 2012 5:37 PM, "Carsten Ziegeler" <[email protected]> wrote: >> >> Hi, >> >> So what about tackling the problem from the other side: we define a >> role in Sling like SCRIPT_ADMIN. When a component in Sling requires a >> script admin, it passes this information into the >> ResourceResolverFactory.loginAdministrative and somehow gets the >> correct resource resolver (and underlying session). > > I like the general idea, but we should make the difference between the "get > admin session" and "get script admin session" very obvious so that users do > not inadvertently grab the admin session. How exactly would the above API > call look like? Good question :) The first thing which comes to my mind is we specify a constant for something like a role and then some constants for known roles:
String AUTH_ATTR_ROLE = "sling:role"; String SCRIPT_ADMIN_ROLE = "scriptAdmin" then you create a map with AUTH_ATTR_ROLE = SCRIPT_ADMIN_ROLE and pass this to loginAdministrative. Carsten > > Bertrand > On Jun 10, 2012 5:37 PM, "Carsten Ziegeler" <[email protected]> wrote: > >> Hi, >> >> I just got aware that we might have potential problems with the way >> script resolving is done atm. >> >> Currently, the script resolver opens a long lived script session. By >> default this is an admin session, but can be configured to user a >> different user. >> The script resolver is used concurrently and therefore the underlying >> session is accessed concurrently which neither by the Sling API nor by >> the JCR API is guaranteed to work. >> In addition, looking at Oak (the new jackrabbit implementation) it >> seems that long lived sessions should refresh themselves before >> reading from the repository. And I guess this is nothing which will >> work concurrently. On the other hand, I don't want to add syncing on >> the resource resolver. >> >> But the problem is slightly larger: other parts in Sling need to have >> access to the script resolver as well. To avoid configuring the same >> script user over and over again in different bundles, we came up with >> the solution that the script resolver buts the used resource resolver >> into a request attribute. This is picked up by e.g. the jsp scripting >> and used there to read scripts (like included jsps etc.) So even if we >> would sync the script resolver, access in the script implementations >> like jsps might happen concurrent (either concurrent to itself or >> concurrent to the script resolver). >> And finally, once a script is resolved by the script resolver, the >> underlying resource keeps a reference to the used resource resolver >> (which in turn references the script session.). The servlet might end >> up in the servlet cache, so we can't close the correspoding script >> resolver otherwise this would render the script resources invalid. >> >> Obviously, one problem arises from the fact that we wanted to >> configure a script user only in one place, otherwise we could solve >> the problems in the script resolver and the (jsp) scripting >> independently. >> >> So what about tackling the problem from the other side: we define a >> role in Sling like SCRIPT_ADMIN. When a component in Sling requires a >> script admin, it passes this information into the >> ResourceResolverFactory.loginAdministrative and somehow gets the >> correct resource resolver (and underlying session). The configuration >> how to get such a script admin is then a configuration of the resource >> resolver factory or some other module. >> This would allow the script resolution to use such a user as well as >> the jsp scripting without passing the resource resolver from one to >> another. >> In addition, this could also be used in the servlet resource provider: >> if the user is not a script admin the resource is not accessible. >> >> The script resolution creates the required resource resolvers on >> demand and does not hold a long lived reference anymore. This solves >> the potential concurrency problems. >> As the final step, we have to make sure that the (cached) >> servlet/script does not hold a reference to a script resource resolver >> forever, it can get them on demand. There shouldn't only be a few uses >> of this. >> >> There might be some wringles to straighten, but WDYT about this in general? >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> [email protected] >> -- Carsten Ziegeler [email protected]
