Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <46A9AD30.5070501@day.com>
Date: Fri, 27 Jul 2007 10:30:40 +0200
From: Angela Schreiber <anchela@day.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: public review of 283 - checkPermission
References: <76a6ebd00707260657w1b55b35fm294bcb1a3ab892d4@mail.gmail.com>
	 <5f211bd50707260729k5aa249bbse200db7faaa7b727@mail.gmail.com>
	 <90a8d1c00707260736l7b95ba0ble5f2f72888ec9358@mail.gmail.com>
	 <46A8BC33.9030601@day.com>
	 <76a6ebd00707260827j171e25ap134655ca8e0f6690@mail.gmail.com>
 <5f211bd50707261326p15b860a3nfb649ed811d64a59@mail.gmail.com>
In-Reply-To: <5f211bd50707261326p15b860a3nfb649ed811d64a59@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

hi thomas

 > I saw "boolean AccessControlManager.hasPrivilege(String absPath,
 > String[] privileges)", but I thought it's something different so
 > far...

the main difference from my point of view: the absPath in this
new method must be point to an existing Node, whereas the absPath in 
Session.checkPermission (as far as i understood) points to the Item
to be added/modified/removed... that goes along with the mapping...

> String[] privileges: "an array of Privileges" (should it say "an array
> of privilege names"?).

i think that's a bug (see also issue#309) and i assume that
it was meant to be Privilege[].

> interface Privilege: "Each privilege is identified by a NAME that is
> unique across the set of privileges supported by a repository. JCR
> defines a set of standard privileges in the jcr  namespace".
> 
> I was a bit confused, those privilege names are not the same as the
> 'action strings' defined in Session.checkPermission(..). I found a
> mapping between 'action strings' and 'privilege names' on page 383 in
> the spec. 

without being involved during the initial discussions regarding
access control, i imagine that an attempt was made to create a
content representation of access control, where the privilege
was defined as jcr property of type NAME. later one that approach
was rejected but the spec still has some leftovers (see also the 
PrincipalManager that mentions a nodetype nt:ace).

> Is this mapping required, why not just one one or the other?

honestly, i find it quite confusing.

if the access control feature has been introduces as replacement
(improvement?) for the Session.checkPermission, Session.checkPermission 
should be deprecated.

if however the access control discovery is intended to extend
the limited access control functionality present in jcr 1.0
it should specified accordingly without introducing additional
confusion.

after all i find it strange that a-c-discovery is optional but 
Session.checkPermission is a level 1 feature... and i don't
understand the explanation in '4.9 Permission Checking' how a
jcr impl that does not support the a-c-discovery feature should
implement Session.checkPermission.

> Should they be documented in the Javadocs of the Privilege interface
> as well? What about adding constants in the Privilege interface?

I have the impression, that all NAME constants have been omitted
intentionally due to the namespace remapping feature. and yes,
that's why the JcrConstants.java interface is present in
jackrabbit-jcr-commons project...

> AccessControlManager.hasPrivilege uses an array of privileges, while
> Session.checkPermission(..) uses a string of comma separated 'action
> strings'. This is not consistent; is there a reason for that?

see above.

gruss
angela