sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bertrand Delacretaz (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (SLING-8757) Add option to set/edit access control policies at user homes
Date Fri, 01 Nov 2019 10:23:00 GMT

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

Bertrand Delacretaz edited comment on SLING-8757 at 11/1/19 10:22 AM:
----------------------------------------------------------------------

[~angela] the changes listed above look good to me. Just a nitpick, the {{getJcrPaths}} method
might need a comment to explain why it's needed (re-parsing what the parser provides when
"home" is used).  I haven't looked in detail at the tests.

If we want to support more characters in usernames that's probably something to do consistently
in the grammar. The {{principalsList()}} production probably needs changes to support that,
and the same syntax for usernames should be used throughout. So it's maybe better to consider
this as a separate change that applies to the parser more globally. That's also related to
SLING-7143, which is about expanding the character set for paths.

And BTW if you want to limit the function names to just "home" for now that's fine with me,
it's probably better to start with this more restrictive syntax and open it up later if really
needed.


was (Author: bdelacretaz):
[~angela] the changes listed above look good to me. Just a nitpick, the {{getJcrPaths}} method
might need a comment to explain why it's needed (re-parsing what the parser provides when
"home" is used).  I haven't looked in detail at the tests.

If we want to support more characters in usernames that's probably something to do consistently
in the grammar. The {{principalsList()}} production probably needs changes to support that,
and the same syntax for usernames should be used throughout. So it's maybe better to consider
this as a separate change that applies to the parser more globally. That's also related to
SLING-7143, which is about expanding the character set for paths.

> Add option to set/edit access control policies at user homes
> ------------------------------------------------------------
>
>                 Key: SLING-8757
>                 URL: https://issues.apache.org/jira/browse/SLING-8757
>             Project: Sling
>          Issue Type: Improvement
>          Components: Repoinit
>            Reporter: Angela Schreiber
>            Priority: Major
>             Fix For: Repoinit Parser 1.3.2, Repoinit JCR 1.1.16
>
>
> [~rombert], while looking into moving all service user creation and permission setup
from content packages to repo init, i noticed that there is one special case that doesn't
seem to be covered by repo init but possible with Jackrabbit content packages: creating/editing
access control policies at a user home. the path of those is an implementation detail and
cannot be 'guessed'.
> based on my previous work on the repo-init grammar, i could envision the following main
options to include this functionality.
> # explicitly extend the 'path-token' which is currently defined to be {{(PATH_STRING>
| t = <PATH_REPOSITORY>)}} to something like {{(PATH_STRING> | t = <PATH_REPOSITORY>
| <USER_ID>)}}.
> # similar to the first one: but don't touch the grammar just extend the jcr-implementation:
if 'path' is a relative path and is not _repository_, treat it as userId and try to obtain
a path from the corresponding user object.
> # completely separate it from the 'pathList' and don't allow a combination of absolute
paths, repository-marker and userIds, explicitly include the notion that the edited policy
is not bound to a regular path but to a user home.... instead of {{on /abspath, repository}}
it then would e.g. say {{on user id1, id2}}
> without having looked into it in great detail and given the fact that there are already
so many different ways to edit access control content with repo-init, the first option would
feel the most natural to me. 
> wdyt? i could try to come up with a patch/tests/docu, but i would love to avoid investing
a lot of time and then have to throw it away or redo it all over again.



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

Mime
View raw message