I believe at one point this impersonateFromService was implemented using an
admin session, i.e. essentially ignoring the "my-service" service user name
argument. And maybe that implementation is still used in AEM 6.3. However, the
current state of Sling and Oak would actually use a service
Hey Jörg, Alexander,
Maybe it's just me, but for me the method works (on an AEM 6.3) without putting
any impersonators on any user, thats why I of course mentioned the method, else
it wouldn't have answered the question:
def session = slingRepository.impersonateFromService("my-service", new
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
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
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-
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
On Tue, Feb 6, 2018 at 1:02 PM, Jörg Hoh 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