You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2015/11/04 17:22:00 UTC
Removing loginAdministrative, how to test that, and service username conventions
Hi,
Antonio recently created a bunch of "Remove loginAdministrative()
usage" tickets for several of our components (SLING-5227 for example).
While replacing the login calls is easy, I'm wondering how to test
these changes.
Do we have a simple mechanism for creating service users in
integration and mock tests?
I also think we need to define a name convention for these services
users, do we prefix their names with sling- for example?
-Bertrand
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 05.11.15 um 09:41 schrieb Bertrand Delacretaz:
> On Thu, Nov 5, 2015 at 9:35 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...I personally would prefer having everything in the provisioning model
>> instead of "hiding" it in bundles - no matter how it really ends up in
>> the runtime...
>
> That would work but for testing I think we also need a utility to
> process such provisioning models at runtime. For example when testing
> outside of the OSGi environment, just with a SlingRepository.
>
Sure, we can put the code processing the model in a common module and
use it from various places.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Nov 5, 2015 at 9:35 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I personally would prefer having everything in the provisioning model
> instead of "hiding" it in bundles - no matter how it really ends up in
> the runtime...
That would work but for testing I think we also need a utility to
process such provisioning models at runtime. For example when testing
outside of the OSGi environment, just with a SlingRepository.
-Bertrand
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 04.11.15 um 19:17 schrieb Robert Munteanu:
> On Wed, 2015-11-04 at 18:51 +0100, Carsten Ziegeler wrote:
>> Am 04.11.15 um 17:26 schrieb Bertrand Delacretaz:
>>> On Wed, Nov 4, 2015 at 5:22 PM, Bertrand Delacretaz
>>> <bd...@apache.org> wrote:
>>>> ...Antonio recently created a bunch of "Remove
>>>> loginAdministrative()
>>>> usage" tickets for several of our components (SLING-5227 for
>>>> example)....
>>>
>>> This also means backward compatibility issues, as the modified
>>> modules
>>> will require the corresponding service users to exist.
>>>
>>> We probably need a super simple mechanism for creating those users
>>> -
>>> maybe embed their definitions in the corresponding bundles, and let
>>> an
>>> (optional) bundle process them.
>>>
>>
>> No, the user and also the ACL must not be part of the bundle - it is
>> not
>> the concern of the implementation to create the user and setup the
>> ACLs.
>> We must not mix these things.
>> And this is also fragile, bringing in yet another mechanism to do
>> something does not make our system more stable. We already have most
>> pieces in place for provisioning: the OSGi installer and friends.
>> For installing content, and users and ACLs are content, we have the
>> JCR
>> contentloader.
>>
>> I suggest we create for each feature a separate bundle with the user
>> definition and the ACLs. The stuff gets then installed - like any
>> other
>> content - through the contentloader.
>
> A brief look at the jcr.contentloader bundle leads me to believe that
> we do not have support for installing users and ACLs, and must add it
> instead.
>
Ok, but that shouldn't be too hard and is imho the better approach
compared to add yet another bundle listening for bundles and doing
something.
We also must be very clear and what happens when such bundle gets
uninstalled, no matter which approach we take.
But my main point is: let's not mix concerns just because its easy for
the developer.
Now another option is to do some additional handling in the provisioning
model, so instead of creating an artificial bundle, we could support
having a "free" text section in the provisioning model which then gets
processed in some way. I think, this would be the easiest way: you
define the service user, security configuration (which is already part
of the provisioning model) and ACLs as part of the provisioning model.
That's super easy, user friendly and we just need to find a way to get
this interpreted. Easiest way, the tooling creates a bundle :) which
then gets picked up by the jcr contentloader.
I personally would prefer having everything in the provisioning model
instead of "hiding" it in bundles - no matter how it really ends up in
the runtime.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2015-11-04 at 18:51 +0100, Carsten Ziegeler wrote:
> Am 04.11.15 um 17:26 schrieb Bertrand Delacretaz:
> > On Wed, Nov 4, 2015 at 5:22 PM, Bertrand Delacretaz
> > <bd...@apache.org> wrote:
> > > ...Antonio recently created a bunch of "Remove
> > > loginAdministrative()
> > > usage" tickets for several of our components (SLING-5227 for
> > > example)....
> >
> > This also means backward compatibility issues, as the modified
> > modules
> > will require the corresponding service users to exist.
> >
> > We probably need a super simple mechanism for creating those users
> > -
> > maybe embed their definitions in the corresponding bundles, and let
> > an
> > (optional) bundle process them.
> >
>
> No, the user and also the ACL must not be part of the bundle - it is
> not
> the concern of the implementation to create the user and setup the
> ACLs.
> We must not mix these things.
> And this is also fragile, bringing in yet another mechanism to do
> something does not make our system more stable. We already have most
> pieces in place for provisioning: the OSGi installer and friends.
> For installing content, and users and ACLs are content, we have the
> JCR
> contentloader.
>
> I suggest we create for each feature a separate bundle with the user
> definition and the ACLs. The stuff gets then installed - like any
> other
> content - through the contentloader.
A brief look at the jcr.contentloader bundle leads me to believe that
we do not have support for installing users and ACLs, and must add it
instead.
Robert
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Nov 5, 2015 at 9:48 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...Keeping it separate from the beginning is the clearest way and works in
> all cases...
I agree as long as that separation does not complicate things more
than strictly needed - provisioning model sounds good, whereas having
to create extra bundles is a hassle.
-Bertrand
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 05.11.15 um 09:39 schrieb Bertrand Delacretaz:
> Hi,
>
> On Wed, Nov 4, 2015 at 6:51 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...I suggest we create for each feature a separate bundle with the user
>> definition and the ACLs. The stuff gets then installed - like any other
>> content - through the contentloader....
>
> So taking SLING-5227 as an example (the contrib/bgservlets module) you
> suggest (option A) creating a companion bgservlets-users bundle that
> provides the user/ACL definitions?
>
> That would work, but I think my suggestion (option B) is simpler:
> include those default definitions in the main bundle, but by default
> to not install the service that processes them.
>
> So by default no users/ACLs are created, and if you want backwards
> compatibility or for testing purposes you just install a single bundle
> that processes those embedded definitions.
>
> This means those definitions need to use a different mechanism than
> our current contentloader (or maybe a new plugin for that
> contentloader) but that's not hard to implement.
>
My main point is: how does the developer of the bgservlets know which
user to use? Which ACLs to apply? There could be a configuration which
changes the default location of the bgservlets stuff in the repository
to a different path. (Maybe this is not possible with the bgservlets,
but it is definitely true for other bundles). Therefore the developer of
the bundle has zero clue and he should not have it. This might be
different on every installation.
If we put this as a default setting which is not processed in the
bundle, assume you have two bundles with such content. You want to have
the defaults of one of them but not the other - how do you handle this?
That can be dealt with of course, but it adds then another thing on top
and makes it much more complicated than it should be.
Keeping it separate from the beginning is the clearest way and works in
all cases.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Nov 4, 2015 at 6:51 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I suggest we create for each feature a separate bundle with the user
> definition and the ACLs. The stuff gets then installed - like any other
> content - through the contentloader....
So taking SLING-5227 as an example (the contrib/bgservlets module) you
suggest (option A) creating a companion bgservlets-users bundle that
provides the user/ACL definitions?
That would work, but I think my suggestion (option B) is simpler:
include those default definitions in the main bundle, but by default
to not install the service that processes them.
So by default no users/ACLs are created, and if you want backwards
compatibility or for testing purposes you just install a single bundle
that processes those embedded definitions.
This means those definitions need to use a different mechanism than
our current contentloader (or maybe a new plugin for that
contentloader) but that's not hard to implement.
-Bertrand
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 04.11.15 um 17:26 schrieb Bertrand Delacretaz:
> On Wed, Nov 4, 2015 at 5:22 PM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> ...Antonio recently created a bunch of "Remove loginAdministrative()
>> usage" tickets for several of our components (SLING-5227 for example)....
>
> This also means backward compatibility issues, as the modified modules
> will require the corresponding service users to exist.
>
> We probably need a super simple mechanism for creating those users -
> maybe embed their definitions in the corresponding bundles, and let an
> (optional) bundle process them.
>
No, the user and also the ACL must not be part of the bundle - it is not
the concern of the implementation to create the user and setup the ACLs.
We must not mix these things.
And this is also fragile, bringing in yet another mechanism to do
something does not make our system more stable. We already have most
pieces in place for provisioning: the OSGi installer and friends.
For installing content, and users and ACLs are content, we have the JCR
contentloader.
I suggest we create for each feature a separate bundle with the user
definition and the ACLs. The stuff gets then installed - like any other
content - through the contentloader.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 4, 2015 at 5:22 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> ...Antonio recently created a bunch of "Remove loginAdministrative()
> usage" tickets for several of our components (SLING-5227 for example)....
This also means backward compatibility issues, as the modified modules
will require the corresponding service users to exist.
We probably need a super simple mechanism for creating those users -
maybe embed their definitions in the corresponding bundles, and let an
(optional) bundle process them.
-Bertrand
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by 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
>>
>
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by 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
Posted by Marius Petria <mp...@adobe.com>.
On 12/8/15, 4:16 PM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>The require method throws an Exception if the requested permissions
>are not granted.
>
>Using this in a bundle Activator or in a component's activate() method
>causes those activations to fail if permissions are missing, with
>clear messages in the logs to help fix that.
>
>Would that work for your use cases?
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Dec 8, 2015 at 9:28 AM, Marius Petria <mp...@adobe.com> wrote:
> ...2. Development definition of services and their requirements (defined by a developer)
> - this a a bundle concern and is a definition of services (not of users) and their needs
> - it does not say how to get there (create user, add acls, …) just what it needs
> - someServiceName require read on somePath
> - someServiceName optional write on somePath...
How do you see this working?
One simple scenario that comes to mind is a utility that verifies that
specific permissions are granted:
final Session s = repository.loginService(...);
permissionsChecker.forSession(s)
.require("jcr:all", somePath)
.require("jcr:read", anotherPath)
The require method throws an Exception if the requested permissions
are not granted.
Using this in a bundle Activator or in a component's activate() method
causes those activations to fail if permissions are missing, with
clear messages in the logs to help fix that.
Would that work for your use cases?
-Bertrand
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Marius Petria <mp...@adobe.com>.
Hi all,
I think the current proposal makes sense and deals with the deployment concerns of service users. Would it make sense to express also the development requirements for services? I know that has been discussed over and over again but I wonder if instead of choosing one variant over another we could actually have both.
1. Deployment definition of service users and ACLs (defined by a "deployer”)
- this is a provisioning concern and is what Bertrand is proposing (create user, add remove ACLs)
2. Development definition of services and their requirements (defined by a developer)
- this a a bundle concern and is a definition of services (not of users) and their needs
- it does not say how to get there (create user, add acls, …) just what it needs
- someServiceName require read on somePath
- someServiceName optional write on somePath
Some advantages of a separate specification of required capabilities would be
1. The developer focuses only on what its code needs, not on how to install them (this becomes smoking of "content access API").
2. A tool can pick up the development requirements and install them (this can be used at least for testing).
3. A tool can validate the mapping between someServiceName and someServiceUser to be according to the requirements. This can be specifically useful in upgrades you will have a way to see it the repo has what it needs for the new code to work properly.
Marius
On 12/7/15, 3:22 PM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>Hi,
>
>On Mon, Nov 16, 2015 at 11:50 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...do we have a solution now on how to
>> define the service user and ACLs in the provisioning model?...
>
>I'm hoping to find time to work on this soon, for now I had a look at
>the ideas in JCRVLT-61 and chatted with Robert and we came up with the
>following suggestions for two simple mini-languages that we can use in
>our provisioning model:
>
>a) Creating service users (this one is definitely a micro-language ;-)
>
> # comments and blank lines are supported of course
> create service user printService,someService
> delete service user printService,anotherService
>
>b) Setting ACLS from our provisioning model:
>
> # comments and blank lines are supported of course
> set ACL on /libs,/apps with glob */install/*
> remove * for user1,user2
> allow jcr:read for user1,user2
>
> deny jcr:write for user2
> deny jcr:lockManagement for user1
> end
>
>Both mini-languages should be implemented in their own modules so as
>to be reusable in other contexts, automated tests for example, and
>maybe JCRVLT-61 if the Oak folks are interested.
>
>I have created https://issues.apache.org/jira/browse/SLING-5355 for
>this, if someone needs it and can help feel free to jump in!
>
>-Bertrand
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Nov 16, 2015 at 11:50 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...do we have a solution now on how to
> define the service user and ACLs in the provisioning model?...
I'm hoping to find time to work on this soon, for now I had a look at
the ideas in JCRVLT-61 and chatted with Robert and we came up with the
following suggestions for two simple mini-languages that we can use in
our provisioning model:
a) Creating service users (this one is definitely a micro-language ;-)
# comments and blank lines are supported of course
create service user printService,someService
delete service user printService,anotherService
b) Setting ACLS from our provisioning model:
# comments and blank lines are supported of course
set ACL on /libs,/apps with glob */install/*
remove * for user1,user2
allow jcr:read for user1,user2
deny jcr:write for user2
deny jcr:lockManagement for user1
end
Both mini-languages should be implemented in their own modules so as
to be reusable in other contexts, automated tests for example, and
maybe JCRVLT-61 if the Oak folks are interested.
I have created https://issues.apache.org/jira/browse/SLING-5355 for
this, if someone needs it and can help feel free to jump in!
-Bertrand
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Carsten Ziegeler <cz...@apache.org>.
This thread started two weeks ago, do we have a solution now on how to
define the service user and ACLs in the provisioning model? Without this
we shouldn't change our code and switch.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Antonio Sanso <as...@adobe.com>.
hi Betrand,
thanks a lot for starting the email thread for this topic.
I am really keen on try to be as much constant as possible in the various areas where the loginAdministrative should be replaced whit regards to:
- user creation
- ace handling
- testability
As this is a green field for Sling we’d need to find some consensus before proceeding
regards
antonio
On Nov 4, 2015, at 5:22 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> Antonio recently created a bunch of "Remove loginAdministrative()
> usage" tickets for several of our components (SLING-5227 for example).
>
> While replacing the login calls is easy, I'm wondering how to test
> these changes.
>
> Do we have a simple mechanism for creating service users in
> integration and mock tests?
>
> I also think we need to define a name convention for these services
> users, do we prefix their names with sling- for example?
>
> -Bertrand