On 3/17/10 9:49 AM, Felix Meschberger wrote:
>> public class WorkspacePicker implements AuthenticationInfoPostProcessor {
>>    public void postProcess(AuthenticationInfo info, HttpServletRequest
>> request, HttpServletResponse response) {
>>        String host = request.getHeader("Host");
> 
> (NB this is what request.getServerName() reports; I would prefer to use
> the API)
(I seem to recall running into trouble with request.getServerName() and
CDNs, so I just got into the habit of using the Host header.)

> 
> 
>>        if (host != null) {
>>           String[] parts = host.split("\\.");
>>           if (parts.length == 4) {
>>                info.put(AuthenticationInfo.WORKSPACE, parts[0]);
>>           }
>>        }
>>    }
>> }
> 
> I wonder, whether and how this could be coordinated with the virtual
> host configuration stuff we do in the ResourceResolver /etc/map
> configuration. Maybe the ResourceResolverFactory knowing about the
> mapping could implement the interface and use the /etc/map configuration
> for this decision ?
To be clear... I wasn't actually suggesting that this WorkspacePicker be
included in Sling.

But yes, you could definitely implement a similar post processor using
/etc/map if the host nodes had something like:
sling:workspaceName = "wspName"

But as things currently stand, you couldn't implement it in the
JcrResourceResolverFactory class because there would be a circular
reference between commons.auth and jcr.resource.

Justin

> 
>>
>>> - and the
>>> name of the "default scripts" workspace to use might be stored as a
>>> property at the root node of the "private" workspace, or defined by
>>> configuration of the script resource resolver.
>>
>> I'll probably just implement a configuration property for now; even if
>> we supported a root node property, we'll need a default.
> 
> I prefer the configuration property anyway because a repository property
> is not congruent with how we do most of the configuration today (and
> additionally opens the door for very wierd stuff like wsp selected by
> client points to wspd1 for default resolution which in turn would point
> to wspd2 for default resolution and so forth)
> 
> Regards
> Felix

Reply via email to