I had the same question previously. It is not very feasible to configure a
service user as a delegate on each individual human user. Especially when these
human users are constantly added or removed.
This is a question for Oak, I believe.
Cheers,
Alex
> On 07.02.2018, at 14:03, Jörg Hoh <jhoh...@googlemail.com> wrote:
>
> Hi Roy,
>
> that's indeed good news, as it seems to solve the impersonation usecase. On
> the other hand the javadoc is quite clear, that the requirements of the
> impersonation process itself come from the underlying repository. I
> typically use Oak and the Oak documentation at [1] says that with the
> DefaultLoginModule it still requires some kind of prerequisits
> ("Impersonation another user will only succeed if the impersonated user is
> valid (i.e. exists and is not disabled) *and* the the user associated with
> the editing session is allowed to impersonate this user.").
>
>
> Jörg
>
>
>
> [1]
> https://jackrabbit.apache.org/oak/docs/security/authentication/default.html#impersonation
>
>
>
> 2018-02-07 22:50 GMT+01:00 Roy Teeuwen <r...@teeuwen.be>:
>
>> Hey Andres,
>>
>> We had a similar use case to do impersonation, there is another method for
>> that now:
>>
>> https://sling.apache.org/apidocs/sling10/org/apache/
>> sling/jcr/api/SlingRepository.html#impersonateFromService-
>> java.lang.String-javax.jcr.Credentials-java.lang.String-
>>
>> Greets,
>> Roy
>>
>>
>> On 7 Feb 2018, at 20:49, Andres Bott <cont...@andresbott.com> wrote:
>>
>> Maybe a solution would be
>> - deprecate / remove the method ( to avoid old code to run as admin)
>> - rename the class / method and add an info to the log
>>
>> in this way we make sure that old code gets migrated to service users, and
>> the places where it really makes sense to use admin user, the developer
>> should be aware of it.
>>
>> Andres
>>
>>
>> El 2018-02-06 14:09, Bertrand Delacretaz escribió:
>>
>> On Tue, Feb 6, 2018 at 1:02 PM, Jörg Hoh <jhoh...@googlemail.com> wrote:
>>
>> ...Long story short: Is the loginAdministrative() method planned to be
>> removed? If yes, we should clearly give best practices and document how it
>> can be replaced even in the non-trivial cases. If it's going to stay, we
>> should remove the deprecation warning....
>>
>> I think we need to keep warnings that loginAdmin should be used as
>> sparingly as possible.
>> And probably provide some examples where it does make sense to use it.
>> But deprecation might not be the correct term, as you indicate.
>> -Bertrand
>>
>>
>>
>
>
> --
> Cheers,
> Jörg Hoh,
>
> http://cqdump.wordpress.com
> Twitter: @joerghoh
