jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Login parameters
Date Mon, 29 Jul 2013 09:40:04 GMT
Hi

Am 29.07.2013 um 11:20 schrieb Jukka Zitting:

> Hi,
> 
> It would be useful to be able to pass in extra parameters in a
> Repository.login() call, in order to for example control the
> auto-refresh or read-only status of the created session. Unfortunately
> the standard JCR API doesn't provide any straightforward way to do
> this, so I've come up with a few potential solutions:

> 
> 1. Use the attribute feature of SimpleCredentials to pass such parameters:
> 
>    SimpleCredentials credentials = ...;
>    credentials.setAttribute("AutoRefresh", true);
>    Session session = repository.login(credentials, ...);
> 
> The downside is that it's tied to the specific Credentials class being used.

Yes, but this would be my favourite: For example in Apache Sling we have an authentication
framework which allows plugging in a service which processes credential data (a Map<String,
Object> later converted to SimpleCredentials with attributes). A service could be devised
to set these flags depending on some configuration or request property.

> 
> 2. Use the URI query parameter syntax to pass such parameters as a
> part of the workspace name:
> 
>    String workspace = ...;
>    Session session = repository.login(..., workspace + "?AutoRefresh=true");
> 
> The downside is the extra complexity of parsing the workspace string
> and the need to in many case look up the default workspace name
> (unless we define "?..." to refer to the default workspace).

Looks clumsy to me. After all the workspace name is a name not an URI.

> 
> 3. Extend the JackrabbitRepository interface with a new login() method
> that explicitly allows such extra parameters:
> 
>    Map<String, Object> parameters =
>        Collections.singletonMap("AutoRefresh", true);
>    Session session = repository.login(..., parameters);
> 
> The downside is the need for the custom API extension and the
> adjustments to all relevant implementations. We probably could justify
> adding such a method in JCR 2.1.

Agreed. Plus this would be the fourth login method ... How many are there to come ?

> 
> 4. Add a new utility class that uses a thread-local variable to pass
> such extra parameters through a normal login() call:
> 
>    Map<String, Object> parameters =
>        Collections.singletonMap("AutoRefresh", true);
>    Session session = LoginWrapper.login(repository, ..., parameters);
> 
> The downside is the need for the custom utility class, and the extra
> complexity (especially for remoting) of using thread-local variables.

Plus: this is hacky and leads to implementation dependent code à-la

> if (isJackrabbit) {
>   doLoginWrapper
> } else {
>   doRepositoryLogin
> }


Regards
Felix

> 
> WDYT?
> 
> BR,
> 
> Jukka Zitting


Mime
View raw message