[
https://issues.apache.org/jira/browse/SLING-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-9857:
------------------------------------
Description:
Sling repoinit allows to create users/groups/service users with an optional
intermediate path (absolute or relative):
{code}
create service user my-feature-service with path system/my-feature
create user my-feature-user with path /home/users/my-feature
create group my-feature-group with path my-feature
{code}
however, in case the user/group/service user already exists the intermediate
path will be ignored.
imo, there should be a way to make sure the intermediate path is respected upon
execution of {{CreateUser}}, {{CreateGroup}} and {{CreateServiceUser}}
operations.
for example:
h4. always verify and adjust path if needed
in {{UserVisitor}}: if a group/user/service user already exists and the
create-operation includes a path (i.e. {{getPath()}} doesn't return {{null}}),
verify that {{Authorizable.getPath()}} is a descendant of that path. If that's
not the case move the corresponding node by either deleting and recreating the
user/group/service user or by actually moving.
h4. global configuration option
expand the repoinit such that handling of intermediate path can be configured
for all statements. for example add a configuration option to
{{JcrRepoInitOpsProcessorImpl}}. {{UserVisitor}} would only perform the
verification and potentially move, if the configuration option mandates it.
the configuration could either be a simple boolean flag for this particular
case or be more sophisticated like e.g.
{{http://jackrabbit.apache.org/filevault/importmode.html}}.
h4. expand repo-init statements
if enforcing intermediate paths should not be dealt on a global level but on a
case by case basis, the create user/group/service user statements needed to be
expanded to allow for more fine-grained setup. as with the previous option it
could be a simple flag or follow the example of {{Jackrabbit-fvault}}, which
defines a variety of import modes (see
http://jackrabbit.apache.org/filevault/importmode.html).
h4. on a general note:
i see the benefit of the fine-grain import-modes (and ac-handling flags on top
of that,
http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling))
in jackrabbit-fvault. however, in a repository setup with many features, it
becomes increasingly difficult to manage and my personal preference would
rather be to keep it simple.
note though SLING-6423: the fvault ac-handling flags already found their way
into the parser (implementation still missing though). so, maybe this issue
here in combination with SLING-6423 could be used to make a conscious decision
about the future development of repo-init and whether or not additional
flexibility is desirable/needed.
was:
Sling repoinit allows to create users/groups/service users with an optional
intermediate path (absolute or relative):
{code}
create service user my-feature-service with path system/my-feature
create user my-feature-user with path /home/users/my-feature
create group my-feature-group with path my-feature
{code}
however, in case the user/group/service user already exists the intermediate
path will be ignored.
imo, there should be a way to make sure the intermediate path is respected upon
execution of {{CreateUser}}, {{CreateGroup}} and {{CreateServiceUser}}
operations.
for example:
h4. always verify and adjust path if needed
in {{UserVisitor}}: if a group/user/service user already exists and the
create-operation includes a path (i.e. {{getPath()}} doesn't return {{null}}),
verify that {{Authorizable.getPath()}} is a descendant of that path. If that's
not the case move the corresponding node by either deleting and recreating the
user/group/service user or by actually moving.
h4. global configuration option
expand the repoinit such that handling of intermediate path can be configured
for all statements. for example add a configuration option to
{{JcrRepoInitOpsProcessorImpl}}. {{UserVisitor}} would only perform the
verification and potentially move, if the configuration option mandates it.
the configuration could either be a simple boolean flag for this particular
case or be more sophisticated like e.g.
{{http://jackrabbit.apache.org/filevault/importmode.html}}.
h4. expand repo-init statements
if enforcing intermediate paths should not be dealt on a global level but on a
case by case basis, the create user/group/service user statements needed to be
expanded to allow for more fine-grained setup. as with the previous option it
could be a simple flag or follow the example of {{Jackrabbit-fvault}}, which
defines a variety of import modes (see
http://jackrabbit.apache.org/filevault/importmode.html).
h4. on a general note:
i see the benefit of the fine-grain import-modes (and ac-handling flags on top
of that,
http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling))
in jackrabbit-fvault. however, in a repository setup with many features, it
becomes increasingly difficult to manage and my personal preference would be
rather be to keep it simple.
note though SLING-6423: the fvault ac-handling flags already found their way
into the parser (implementation still missing though). so, maybe this issue
here in combination with SLING-6423 could be used to make a conscious decision
about the future development of repo-init and whether or not additional
flexibility is desirable/needed.
> Intermediate path is ignored if user/group already exists
> ---------------------------------------------------------
>
> Key: SLING-9857
> URL: https://issues.apache.org/jira/browse/SLING-9857
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
> Reporter: Angela Schreiber
> Priority: Major
>
> Sling repoinit allows to create users/groups/service users with an optional
> intermediate path (absolute or relative):
> {code}
> create service user my-feature-service with path system/my-feature
> create user my-feature-user with path /home/users/my-feature
> create group my-feature-group with path my-feature
> {code}
> however, in case the user/group/service user already exists the intermediate
> path will be ignored.
> imo, there should be a way to make sure the intermediate path is respected
> upon execution of {{CreateUser}}, {{CreateGroup}} and {{CreateServiceUser}}
> operations.
> for example:
> h4. always verify and adjust path if needed
> in {{UserVisitor}}: if a group/user/service user already exists and the
> create-operation includes a path (i.e. {{getPath()}} doesn't return
> {{null}}), verify that {{Authorizable.getPath()}} is a descendant of that
> path. If that's not the case move the corresponding node by either deleting
> and recreating the user/group/service user or by actually moving.
> h4. global configuration option
> expand the repoinit such that handling of intermediate path can be configured
> for all statements. for example add a configuration option to
> {{JcrRepoInitOpsProcessorImpl}}. {{UserVisitor}} would only perform the
> verification and potentially move, if the configuration option mandates it.
> the configuration could either be a simple boolean flag for this particular
> case or be more sophisticated like e.g.
> {{http://jackrabbit.apache.org/filevault/importmode.html}}.
> h4. expand repo-init statements
> if enforcing intermediate paths should not be dealt on a global level but on
> a case by case basis, the create user/group/service user statements needed to
> be expanded to allow for more fine-grained setup. as with the previous
> option it could be a simple flag or follow the example of
> {{Jackrabbit-fvault}}, which defines a variety of import modes (see
> http://jackrabbit.apache.org/filevault/importmode.html).
> h4. on a general note:
> i see the benefit of the fine-grain import-modes (and ac-handling flags on
> top of that,
> http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling))
> in jackrabbit-fvault. however, in a repository setup with many features, it
> becomes increasingly difficult to manage and my personal preference would
> rather be to keep it simple.
> note though SLING-6423: the fvault ac-handling flags already found their way
> into the parser (implementation still missing though). so, maybe this issue
> here in combination with SLING-6423 could be used to make a conscious
> decision about the future development of repo-init and whether or not
> additional flexibility is desirable/needed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
