jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Edelson <justinedel...@gmail.com>
Subject Re: Help with JCR 2 access control
Date Thu, 02 Sep 2010 02:09:05 GMT
On 9/1/10 5:46 PM, aimran wrote:
> I tried that. Apparently there is no way to set permissions at root level.
Not true.

> Everyone gets read access.
This is true by default, but you can revoke the read privilege for the
"everyone" principal.

> Also, it seems that there is no way to set
> permission such as NO_ACCESS. Everybody gets a read access.
JCR 2 only defines the ability to add privileges. You need to use the
Jackrabbit-specific JackrabbitAccessControlList to add a "deny" access
control entry. To deny access to the workspace entirely, just configure
the ACL on the root node. For example, if you only wanted to allow
members of the "users" group, you could do something like this:

* Find the AccessControlList on the root node
* Remove all the entries from the ACL
* Add an AccessControlEntry for the "users" group granting them jcr:all.

> So, if I want to
> set two top level nodes, DEPT1 & DEPT2, they they both get ready view to
> each other. Cant get them to hide from each other. 
I don't understand what this means. Nodes don't "view" each other. Users
interact with nodes and need different privileges based on their

> Another problem I found is that you have to create a user before you can
> apply the permissions.
What access control mechanism allows you to assign privileges to a user
or group before it exists?

> I didn't find a way to change the password. It is a
> common scenario for users to change password.
Authorizable authorizable =
if (authorizable instanceof User) {

> There is literally no documentation on the access control feature [apart
> from spec, which doesn't talk about usage] so I am forced to believe that
> this is an experimental feature and will take some time to become usable in
> real life scenarios.
While the documentation is sparse, the Jackrabbit and JCR javadocs fill
in most of the holes you're describing IMHO.

> Setting access control in LDAP or RDBMS is such a piece of cake. JCR is so
> weird and convoluted. Ah well, back to relational database [by the time I
> have this figured out, I can have my app working in MySQL]...
Really? While both LDAP and RDBMS's are good at storing access control
information for use in upstream applications, I'm not sure they're
particularly good at enforcing the kind of fine-grained access control
which JCR supports. LDAP is actually not that bad in this regard, but
I've seen some solutions for row-level security in MySQL and they're not
pretty or scalable. And you certainly can't do thing like "let this user
modify properites, but not checkin/checkout".

> Tip to developers: Please make it simpler such as
> node.setPermission(Principal p, Privileges[] priv);. Whats with the 30 lines
> of code to get iterators, looping, creating users, casting...
I completely agree that the JCR security API is complex, perhaps
unnecessarily so. It is also, unfortunately, incomplete and you
frequently have to drop down into Jackrabbit-specific interfaces for
user management and the above-mentioned ability to deny privileges.

I hope that the JCR 2.1 EG can simplify things, but it may be too much
to ask in a dot release. Instead, this is a place where a few utility
methods can go a long way. For example, Sling's AccessControlUtil class
does most of what I need.


View raw message