[RT] Rethinking Script Resolution and Resource Resolvers

[Carsten Ziegeler <cz...@apache.org>]

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
cziegeler@apache.org

Re: [RT] Rethinking Script Resolution and Resource Resolvers

[Carsten Ziegeler <cz...@apache.org>]

2012/6/13 Bertrand Delacretaz <bd...@apache.org>:
> On Jun 10, 2012 5:37 PM, "Carsten Ziegeler" <cz...@apache.org> 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" <cz...@apache.org> 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
>> cziegeler@apache.org
>>



-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] Rethinking Script Resolution and Resource Resolvers

[Bertrand Delacretaz <bd...@apache.org>]

On Jun 10, 2012 5:37 PM, "Carsten Ziegeler" <cz...@apache.org> 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?

Bertrand
On Jun 10, 2012 5:37 PM, "Carsten Ziegeler" <cz...@apache.org> 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
> cziegeler@apache.org
>