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
