Ok, I've hacked a first version into our code - comments welcome :) Carsten
Carsten Ziegeler wrote: > Ok, as noone responded/objected so far, I'll continue this way and > implement it. > > Carsten > > Carsten Ziegeler wrote: >> Hi, >> >> with SLING-1021 now implemented, the initial script searching is done by >> a configurable script admin session. >> Unfortunately this is only one half; the various script implementations >> sometimes try to read the script by themselves or want to read/access >> included scripts etc. Currently these implementations still use the >> session from the current request to do this. >> >> I think the correct solution would be that the script implementations >> use the same session as the script resolution - this would reduce the >> configuration of the script admin user to a single place. >> >> The basic question is now how we want to pass this session from the >> script resolution to the script engines. Now, the transported object is >> definitly the resource resolver (and not the jcr session). >> >> One viable option is to pass the resource resolver as a predefined >> attribute in the javax.script.ScriptContext. >> >> In this context we have another problem :) >> >> The script object passed to the scripts contains the script resource as >> scripts might need this resource. Each resource has the >> getResourceResolver method which now returns a resource resolver using >> the configured script admin user. I'm not 100% sure if this is kind of a >> security problem. If so, this method should return a resource which is >> (lazily) fetched by the resource resolver of the current request. To >> avoid problems we should create a synthetic resource if the current user >> is not allowed to read the script. >> >> WDYT? >> >> Carsten > > -- Carsten Ziegeler [email protected]
