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 (Jira)" <ji...@apache.org> on 2021/01/25 14:18:00 UTC

[jira] [Comment Edited] (SLING-9857) Intermediate path is ignored if user/group already exists

    [ https://issues.apache.org/jira/browse/SLING-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271332#comment-17271332 ] 

Bertrand Delacretaz edited comment on SLING-9857 at 1/25/21, 2:17 PM:
----------------------------------------------------------------------

I have implemented the {{with forced path}} language option in [this commit|https://github.com/apache/sling-org-apache-sling-repoinit-parser/commit/927bd185131382f83d0fb307bd4d97f12b053f79].

And also adapted the {{org.apache.sling.jcr.repoinit}} module to use this updated parser in [this commit|https://github.com/apache/sling-org-apache-sling-jcr-repoinit/commit/d3a8098d9a75bdded80bfa7d248c33f77d8b1733].

The syntax is defined in the [test-68.txt|https://github.com/apache/sling-org-apache-sling-repoinit-parser/blob/master/src/test/resources/testcases/test-68.txt] test which is:
{code:java}
create user A with path /path/user/A
create user AF with forced path /path/user/AF

create service user B with path /path/service/B
create service user BF with forced path /path/service/BF

create group G with path /path/group/G
create group GF with forced path /path/group/GF
{code}
 
As mentioned, I won't have time to do more right now, what's left is to implement the {{org.apache.sling.jcr.repoinit}} changes.


was (Author: bdelacretaz):
I have implemented the {{with forced path}} language option in [this commit|https://github.com/apache/sling-org-apache-sling-repoinit-parser/commit/927bd185131382f83d0fb307bd4d97f12b053f79].

And also adapted the {{org.apache.sling.jcr.repoinit}} module to use this updated parser in [this commit|https://github.com/apache/sling-org-apache-sling-jcr-repoinit/commit/d3a8098d9a75bdded80bfa7d248c33f77d8b1733].

As mentioned, I won't have time to do more right now, what's left is to implement the {{org.apache.sling.jcr.repoinit}} changes.

> 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
>    Affects Versions: Repoinit Parser 1.6.2, Repoinit JCR 1.1.26
>            Reporter: Angela Schreiber
>            Priority: Major
>             Fix For: Repoinit Parser 1.6.4, Repoinit JCR 1.1.28
>
>
> 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 beyond this improvement and whether or not additional flexibility is desirable/needed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)