[
https://issues.apache.org/jira/browse/SLING-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-5355:
---------------------------------------
Description:
As discussed in the "Removing loginAdministrative, how to test that, and
service username conventions" thread on our dev list [1] we need to be able to
create service users and set the corresponding ACLs from our provisioning model.
This should be implemented using distinct utility classes, one for the users
and one for the ACLs, that take simple mini-languages as input. This will allow
for reusing these utilities in test code for example.
[1] http://markmail.org/message/kcvuhwfdald2dyuz
*Edit: high-level requirements*
As discussed in the "SLING-5355 - configs vs. content for ACLs and service
users" thread - http://markmail.org/message/tzno2via2wjckhuc
* HR1 - Create service users and set their ACLs as defined in the Sling
instance's provisioning model.
* HR2 - Create initial paths like /var/discovery, so that ACLs can be set on
them.
* HR3 - Make the full text of the ACL definitions available at runtime for
auditing purposes (see Michael Marth's Dec.17 comment in SLING-5355). Also
useful for upgrades where merging with conflict detection is needed.
was:
As discussed in the "Removing loginAdministrative, how to test that, and
service username conventions" thread on our dev list [1] we need to be able to
create service users and set the corresponding ACLs from our provisioning model.
This should be implemented using distinct utility classes, one for the users
and one for the ACLs, that take simple mini-languages as input. This will allow
for reusing these utilities in test code for example.
I have made a suggestion for those mini languages in that thread, will copy
them here once we agree.
[1] http://markmail.org/message/kcvuhwfdald2dyuz
*Edit: additional contraints*
* AC1: Waiting for content paths: not all ACLs can be applied immediately when
the SlingRepository service starts: for this we'd need to create paths that
don't exist yet, and the nodetypes of those paths might not have been defined
yet, as any bundle can supply additional node types. This means waiting for the
path creation to succeed before proceeding, so we might as well wait for the
paths to be created by content installations
* AC2: The mechanism must work for any launchers, not just the Sling Launchpad
- so it cannot be just a build-time thing.
* AC3: The full text of the ACL definitions must be available at runtime. This
allows for example checking later that a Sling instance is still configured
according to those ACL definitions.
> Create service users and ACLs from the provisioning model
> ---------------------------------------------------------
>
> Key: SLING-5355
> URL: https://issues.apache.org/jira/browse/SLING-5355
> Project: Sling
> Issue Type: New Feature
> Components: Service User Mapper
> Reporter: Bertrand Delacretaz
> Assignee: Bertrand Delacretaz
>
> As discussed in the "Removing loginAdministrative, how to test that, and
> service username conventions" thread on our dev list [1] we need to be able
> to create service users and set the corresponding ACLs from our provisioning
> model.
> This should be implemented using distinct utility classes, one for the users
> and one for the ACLs, that take simple mini-languages as input. This will
> allow for reusing these utilities in test code for example.
> [1] http://markmail.org/message/kcvuhwfdald2dyuz
> *Edit: high-level requirements*
> As discussed in the "SLING-5355 - configs vs. content for ACLs and service
> users" thread - http://markmail.org/message/tzno2via2wjckhuc
> * HR1 - Create service users and set their ACLs as defined in the Sling
> instance's provisioning model.
> * HR2 - Create initial paths like /var/discovery, so that ACLs can be set on
> them.
> * HR3 - Make the full text of the ACL definitions available at runtime for
> auditing purposes (see Michael Marth's Dec.17 comment in SLING-5355). Also
> useful for upgrades where merging with conflict detection is needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
