sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject Re: [RT] Rethinking Script Resolution and Resource Resolvers
Date Wed, 13 Jun 2012 08:29:40 GMT
On Jun 10, 2012 5:37 PM, "Carsten Ziegeler" <cziegeler@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" <cziegeler@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message