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
