Re: Removing loginAdministrative, how to test that, and service username conventions

[Alexander Klimetschek <ak...@adobe.com.INVALID>]

Hi Marius,

AFAICS, what you describe below is exactly my @ServiceUser annotation, just different names and a different syntax for the ACLs :)

Cheers,
Alex

On 08.12.2015, at 08:09, Marius Petria <mp...@adobe.com> wrote:
> I do not have a precise use case right now other than obtaining a “content access contract” that can be used by tools. Basically, I just wanted to emphasize that service requirements in code and install instructions in the provisioning model are two sides of the same coin and we might need both.
> 
> Alexander Klimetschek’s ServiceUser annotation is something close to what I call service requirements but it goes too concrete by embedding ACL commands like (allow /content/dam jcr:read) and by looking to define service users rather than services. A similar annotation @ServiceRequirement could be used for expressing requirements. 
> 
> @ServiceRequirement(permissions = { "/content/mystuff jcr:read”})
> private static final String SERVICE_NAME = “my-service";
> Session session = repository.loginService(SERVICE_NAME, null);
> 
> Then something like the permissionChecker can be called at activate time, or just in webconsole when listing the service user mappings. These annotations can be also used to auto generate service users and ACLs but that should not be automatically installed (except for testing) as the actual users and ACLs should be installed explicitly by the provisioning model.
> 
> Now, imagine I have a bundle that is annotated with @ServiceRequirements then I can just install it in two ways:
> - for testing, I install it with a flag autoGenerateServiceUser=true. This will eliminate the need of defining any additional service user installation in a provisioning model just for that test and the bundle is standalone.
> - for production, I install with autoGenerateServiceUser=false and maybe validateServiceUser=true which will validate against the actual mapping and repository.
> I am not sure how these switches will be specified though this is just a high level wish :).
> 
> 
> 
> Marius
> 

Re: Removing loginAdministrative, how to test that, and service username conventions

[Alexander Klimetschek <ak...@adobe.com.INVALID>]

Ok, I just noticed I replied to a super old thread because my Email app decided to surface it as if it were new :D

Cheers,
Alex

> On 01.10.2018, at 16:19, Alexander Klimetschek <ak...@adobe.com.INVALID> wrote:
> 
> Hi Marius,
> 
> AFAICS, what you describe below is exactly my @ServiceUser annotation, just different names and a different syntax for the ACLs :)
> 
> Cheers,
> Alex
> 
> On 08.12.2015, at 08:09, Marius Petria <mp...@adobe.com> wrote:
>> I do not have a precise use case right now other than obtaining a “content access contract” that can be used by tools. Basically, I just wanted to emphasize that service requirements in code and install instructions in the provisioning model are two sides of the same coin and we might need both.
>> 
>> Alexander Klimetschek’s ServiceUser annotation is something close to what I call service requirements but it goes too concrete by embedding ACL commands like (allow /content/dam jcr:read) and by looking to define service users rather than services. A similar annotation @ServiceRequirement could be used for expressing requirements. 
>> 
>> @ServiceRequirement(permissions = { "/content/mystuff jcr:read”})
>> private static final String SERVICE_NAME = “my-service";
>> Session session = repository.loginService(SERVICE_NAME, null);
>> 
>> Then something like the permissionChecker can be called at activate time, or just in webconsole when listing the service user mappings. These annotations can be also used to auto generate service users and ACLs but that should not be automatically installed (except for testing) as the actual users and ACLs should be installed explicitly by the provisioning model.
>> 
>> Now, imagine I have a bundle that is annotated with @ServiceRequirements then I can just install it in two ways:
>> - for testing, I install it with a flag autoGenerateServiceUser=true. This will eliminate the need of defining any additional service user installation in a provisioning model just for that test and the bundle is standalone.
>> - for production, I install with autoGenerateServiceUser=false and maybe validateServiceUser=true which will validate against the actual mapping and repository.
>> I am not sure how these switches will be specified though this is just a high level wish :).
>> 
>> 
>> 
>> Marius
>> 
>