On 3/19/10 10:16 AM, Felix Meschberger wrote:
>> ResourceResolver scriptResolver =
>> request.getResourceResolver().sudo(scriptUser);
>> try {
>> ... resolve ...
>> } finally {
>> scriptResolver.close();
>> }
>>
>> WDYT?
>
> +1 but name it "impersonate" to align it with JCR API.
OK, just so long as we remember that
ResourceResolver[Factory].impersonate() can't just delegate to
Session.impersonate(). ResourceResolver[Factory].impersonate() should
always work whereas Session.impersonate() can fail based on access
control. That's why I picked sudo... but there are other ways of
remembering the implementation details :)
>
> This would also allow us to reconsider another "problem" we have: The
> Commons Auth bundle currently supports a sudo parameter and cookie to
> actually impersonate another user after initial primary login.
>
> Since I am not sure, whether support for such sudo is correct in the
> Commons Auth layer, it would be usefull to have an impersonation support
> on the ResolverResolver[Factory] level.
>
> We could then move the support for sudo from Commons Auth to the Sling
> Main Servlet, where IMHO it is more appropriate.
>
> Having said this, it might probably be more inline with the rest of the
> API to have a new method on the ResourceResolverFactory:
>
> ResourceResolver impersonate(ResourceResolver resolver,
> Map credentials)
That'd be fine too. I just think having it be on the ResourceResolver
would lead to cleaner code.
Thanks,
Justin
>
> Regards
> Felix
>
>>
>> Justin
>>
>> On Thu, Mar 18, 2010 at 12:40 PM, Justin Edelson
>> <[email protected]>wrote:
>>
>>> Hi,
>>>
>>> This is a longish email which I wrote in bursts over a few hours, so I
>>> apologize in advance if it's not completely coherent. Basically, I think
>>> we should do both... allow for the request's workspace to be used for
>>> script resolution AND provide the ability to mount non-default
>>> workspaces under the resource tree (i.e. /security -> the root node of
>>> the security workspace).
>>>
>>> On 3/18/10 2:19 AM, Carsten Ziegeler wrote:
>>>> Right, the question here is how to solve use cases like Justin's and I
>>>> think that solving this through the resource tree is the most elegant
>>>> way (and we have nearly everything for this in place since we started
>>>> with the resource tree).
>>>>
>>>> Carsten
>>>
>>> I thought about this a lot yesterday and I'm still of the mind mounting
>>> workspaces inside the resource tree is NOT the right way to accomplish
>>> the use cases I sent. This isn't to say we shouldn't do that, but I
>>> think we're fundamentally describing two different things.
>>>
>>> To my mind, at present Sling's resource tree is composed of a JCR
>>> workspace with 0 or more resource providers layered on top of the
>>> workspace's node tree (bundle, fs, etc.). For the purpose of the use
>>> cases I described yesterday, I am talking about replacing the base layer
>>> of the resource tree. We allow this today, it just doesn't work for
>>> script resolution (because of the specific need in script resolution to
>>> use a different session).
>>>
>>> I can see how a combination of mounting non-default workspaces and
>>> /etc/map can accomplish some of what I described. However, since both
>>> /etc/map and SlingServletResolver.getSearchPath() are static, it feels
>>> very limited. For example, if I wanted to service a request for
>>> http://v1.site.com/content/index.html using a node called /content/index
>>> and a script in a node /apps/myco/page, where both nodes are in the v1
>>> workspace, I would need an /etc/map entry with
>>> v1.site.com
>>> sling:internalRedirect=/v1
>>>
>>> AND
>>> the search path needs to be /v1/apps, /v1/libs, /apps, /libs
>>>
>>> Then I add v2.
>>> v2.site.com
>>> sling:internalRedirect=/v2
>>>
>>> AND
>>> the search path needs to be /v2/apps, v2/libs, /v1/apps, /v1/libs,
>>> /apps, /libs
>>>
>>>
>>> There is now no way to properly serve scripts from v1 anymore (AFAICT).
>>>
>>> Perhaps a different way of looking at this...
>>>
>>> ResourceResolverFactory needs a method that says "create a new
>>> ResourceResolver, using this other ResourceResolver as a guide, but with
>>> alternate authentication."
>>>
>>> Looking at SlingServletResolver, something like this is needed anyway in
>>> order to make SlingServletResolver independent of JCR.
>>>
>>> Again, none of this is to say that we shouldn't ALSO do a secondary
>>> resource provider which mounts a non-default workspace within the
>>> resource tree.
>>>
>>> Finally, it's worth noting that mounting additional workspaces under the
>>> resource tree doesn't obviate the need for initial content loading and
>>> observation/event support across multiple workspaces. In fact, it makes
>>> the latter more complicated in that JCRResourceListener now needs to map
>>> a path in a non-default workspace to an absolute resource path. I would
>>> be surprised if JCRResourceListener was the only place we assumed that
>>> JCR path == resource path.
>>>
>>> Justin
>>>
>>
