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