Well, there are far easier ways to get rid of the deprecation warning than introducing a new interface to the API.
Adding a comment like NOSONAR (at least that's what I remember it is) solves that issue. Regards Carsten Georg Henzler wrote > I think the initial motivation are the two points in [1] > > For "Package installation and deployment." it's > easy enough to define a user with the path he may write > to (this is actually a good exercise). > >> To emulate this this with a system user, I have to >> configure every user to allow impersonation from this >> service user > > Why don't we allow somehow to configure "*" for who a > service user can impersonate? Should be easy to > implement in oak.... > > For potential remaining cases (especially in platform code) > it is not nice to have the deprecation warning in the code > I suppose (think SonarQube etc.). Why don't we introduce > an interface LegitimateAdminSessionUsage with a method > getAdminResolver() that is not deprecated? (I would still > require the LoginAdminWhitelist config). That way we leave > the service user mechanism untouched (I think we should!) > and code in need can use the following: > > ResourceResolver adminResourceResolver = > ((LegitimateAdminSessionUsage) rrf).getAdminResolver(); > > Having a new interface makes it easy for code reviews > to grep over the code and immediately see where an > admin session is used. It is enough to document it in > Javadoc, most of the world should not need it/know about it. > > -Georg > > [1] > http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html > > > > > On 2018-07-28 10:23, Carsten Ziegeler wrote: >> I'm not sure if we should go this way. Today you can just look at the >> code and you know whether admin is used or not. Hiding this behind the >> same api and defering it to configuration makes it very hard to do sane >> code checks. >> >> Maybe we should step back and ask what exact problem are we trying to >> solve? >> >> Carsten >> >> >> Dominik Süß wrote >>> +1 - instead of whitelisted calls of the loginadmin call the mapping to >>> admin could be whitelisted. Btw.the very early versions of >>> servicemapping >>> did allow to map to any user including admin which was used as temporary >>> bridge until all the initial hiccups with service users were sorted >>> out (at >>> least by developers aware of that option - just remember because those >>> admin mappings had thento be removed to be able to eliminate this >>> option. >>> >>> Cheers >>> Dominik >>> >>> Jörg Hoh <[email protected]> schrieb am Fr. 27. Juli >>> 2018 um >>> 17:17: >>> >>>> Hi >>>> >>>> 2018-07-27 16:41 GMT+02:00 Jason E Bailey <[email protected]>: >>>> >>>>> I may be off base here since I haven't spent much time with service >>>>> users >>>>> but couldn't this be handled by extending the Service User so that >>>>> for >>>>> specific services, the user returned is the literal admin user. >>>>> >>>>> i.e. rather then whitelisting the services that can use >>>>> loginAdministrative the service user that these whitelisted services >>>> would >>>>> get would be the Administrator user. >>>>> >>>> >>>> That means, that instead of the service-user you can configure to >>>> receive >>>> the admin-user? I guess, that it won't change much... Instead of >>>> creating a >>>> new service-user lazy people will use the admin. One could argue, >>>> that it's >>>> still to easy to use an admin session. But harmonizing both approaches >>>> would definitley help, because then a switch from a service-user to an >>>> admin-user and vice-versa would be just a configuration change, but >>>> no code >>>> change. >>>> >>>> Jörg >>>> >>>> -- >>>> Cheers, >>>> Jörg Hoh, >>>> >>>> http://cqdump.wordpress.com >>>> Twitter: @joerghoh >>>> >>> -- Carsten Ziegeler Adobe Research Switzerland [email protected]
