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 user, and your code might fail to work.
But when I searched, I couldn't find the source code showing that history. Does anyone know? Cheers, Alex > On 08.02.2018, at 01:07, Roy Teeuwen <r...@teeuwen.be> wrote: > > 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 > SimpleCredentials("my-user", "".toCharArray()), (String)null); > > Maybe this is a security flaw :)? The reason I use it like this is because I > also found that AEM itself uses this method to modify pages in name of users > in workflows / jobs... > > Greets, > Roy > >> On 8 Feb 2018, at 00:25, Alexander Klimetschek <aklim...@adobe.com.INVALID> >> wrote: >> >> 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 >> >
signature.asc
Description: Message signed with OpenPGP