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
