Bertrand Delacretaz wrote
> On Tue, Dec 29, 2015 at 10:43 AM, Carsten Ziegeler <[email protected]>
> wrote:
>> ...If we simply
>> require a comment on the same line as the loginAdmin (just as an
>> example) a simple grep works ootb....
>
> That's not sufficient, IMO the SLING-5135 requirement is:
>
> If "admin safe" mode is enabled, loginAdmin fails *unless* the code
> that calls is is marked with the reason why it's needed.
Don't want to be a pita, but that requirement is not in the issue :)
Who has the control of what is allowed and what is not?
Is it the caller? then yes it must provide a good reason.
Is it the called service? Then how can it check the reason for being a
good reason?
We should clarify that question first.
Why can't we simply use the same concept as for the service users?
The caller bundle needs to be in a list of allowed bundles.
PS: The below approach adds new api (an annotation) as well :)
Regards
Carsten
>
> An inline comment works for static code analysis but cannot cause
> existing code to fail, which we want.
>
> You have a good point about keeping the code compatible with older
> modules - if we don't want any API changes we might use a method
> annotation to indicate the reason:
>
> @RequiresLoginAdmin("setting ACL at startup")
> void doSometing() {
> Session s = repository.loginAdministrative()
> }
>
> We'd need to go up the stack trace to grab the annotation in the
> loginAdmin code, but as we require the direct caller to have the
> annotation it shouldn't be too costly.
>
> WDYT?
>
> -Bertrand
>
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
