Hi,
On 19.03.2010 04:15, Justin Edelson wrote:
> This bit:
>
>> Looking at SlingServletResolver, something like this is needed anyway in
>> order to make SlingServletResolver independent of JCR.
>
> is wrong. Not sure what I was thinking.
>
> But... in figuring out I was wrong, I came up with a better solution:
>
> Instead of:
>> ResourceResolverFactory needs a method that says "create a new
>> ResourceResolver, using this other ResourceResolver as a guide, but with
>> alternate authentication.
>
> How about if ResourceResolver has a "sudo" method which returns a new
> ResourceResolver. Then SlingServletResolver could do something like this
> when resolving:
>
> ResourceResolver scriptResolver =
> request.getResourceResolver().sudo(scriptUser);
> try {
> ... resolve ...
> } finally {
> scriptResolver.close();
> }
>
> WDYT?
+1 but name it "impersonate" to align it with JCR API.
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)
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
>>
>
