From dev-return-102541-archive-asf-public=cust-asf.ponee.io@sling.apache.org Wed Jan 22 12:50:03 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 09E9B18064C for ; Wed, 22 Jan 2020 13:50:02 +0100 (CET) Received: (qmail 51611 invoked by uid 500); 22 Jan 2020 12:50:02 -0000 Mailing-List: contact dev-help@sling.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@sling.apache.org Delivered-To: mailing list dev@sling.apache.org Received: (qmail 51599 invoked by uid 99); 22 Jan 2020 12:50:02 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Jan 2020 12:50:02 +0000 Received: from jira-he-de.apache.org (static.172.67.40.188.clients.your-server.de [188.40.67.172]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id B3147E00CD for ; Wed, 22 Jan 2020 12:50:01 +0000 (UTC) Received: from jira-he-de.apache.org (localhost.localdomain [127.0.0.1]) by jira-he-de.apache.org (ASF Mail Server at jira-he-de.apache.org) with ESMTP id 3812E7806AE for ; Wed, 22 Jan 2020 12:50:00 +0000 (UTC) Date: Wed, 22 Jan 2020 12:50:00 +0000 (UTC) From: "Angela Schreiber (Jira)" To: dev@sling.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (SLING-8757) Add option to set/edit access control policies at user homes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SLING-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021021#comment-17021021 ] Angela Schreiber commented on SLING-8757: ----------------------------------------- [~bdelacretaz], my patches are ready for being reviewed an possibly merged. since the were built on top of your patch for the parser, i didn't want to create a pull request as the parser changes probably needed to go first (note though that i additionally added constants to the repoinit-parser module). i for sure won't have time this week, so feel free to pick up my patch... > 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 JCR 1.1.18, Repoinit Parser 1.3.4 > > > [~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 = )}} to something like {{(PATH_STRING> | t = | )}}. > # 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)