From jackrabbit-dev-return-2199-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Wed Jun 01 14:58:47 2005 Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 95880 invoked from network); 1 Jun 2005 14:58:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Jun 2005 14:58:47 -0000 Received: (qmail 55700 invoked by uid 500); 1 Jun 2005 14:58:46 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 55669 invoked by uid 99); 1 Jun 2005 14:58:45 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from 93sirius042.dc.ukrtel.net (HELO 93sirius042.dc.ukrtel.net) (195.5.55.42) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 01 Jun 2005 07:58:43 -0700 Received: from max.office (max.office [192.168.0.71]) by 93sirius042.dc.ukrtel.net (Postfix) with ESMTP id 47CFC8A4AC for ; Wed, 1 Jun 2005 17:58:29 +0300 (EEST) Date: Wed, 1 Jun 2005 17:58:28 +0300 From: Maxim X-Mailer: The Bat! (v1.61) Reply-To: Maxim X-Priority: 3 (Normal) Message-ID: <9830580372.20050601175828@anahoret.com> To: Jukka Zitting Subject: Re[2]: User permissions in JCR In-Reply-To: <429DC262.9080306@zitting.name> References: <4325744999.20050601163754@anahoret.com> <429DC262.9080306@zitting.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hello jackrabbit-dev. At first I thank Jukka Zitting for his elaborate comment. Since JCR specification is finalized, I do not expect any changes in API soon. But the question of proper implementing of user permission in JCR is still open. Wednesday, June 1, 2005, 5:12:50 PM, Jukka Zitting wrote: >> If, as JCR states, permission system is left up to implementation, >> then is such application forced to used some proprietary API to set >> permissions? Doesn't this compromise entirely a concept of "switching >> repository implementations" and avoiding vendor lock-in? > There are a number of applications that never need to manage access > control settings, or handle more fine-grained access settings using > application-level flags or ACLs. > Do you have some specific use case in mind? It would be interesting to > discuss the "correct" way to implement such "permission-intensive" > applications on top of JCR. Consider an enterprise-level web-based knowledge management and collaboration tool, similar to Wiki but hierarchical, with all data stored in JCR. Various types of users (e.g. managers or editors) should be able to set permissions for newly added or existing folders to enable proper level of disclosure of sensitive data. In a such dynamic environment various working groups are created and disbanded often, and usually such groups has their own space (folder) in repository with write access while some other groups may have read access to this folder. As far as I can see, such application will inevitable use an extended (proprietary) API to allow each user to set permissions. Notably CRX, a commercial product of Day Software contains its own (apparently nonstandard) implementations of permissions based on ACLs. For the next generation of JCR (maybe JCR 2.0) I can only suggest to consider adding an AccessManager interface similar to QueryManager with a few built-in implementations. These could be - simle superuser/anonymous, like currently in Jackrabbit - UNIX filesystem, - NTFS filesystem (ACLs based) - Generic ACLs (similar to Day implementation) So applications will be able to either choose form existing variant or implement their own scheme. It would be interesting to hear some comments in this issue. Thank you. -- Best regards, Maxim. Anahoret Team.