jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Trivial Update of "AccessControl" by angela
Date Wed, 09 Mar 2011 09:15:57 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "AccessControl" page has been changed by angela.
http://wiki.apache.org/jackrabbit/AccessControl?action=diff&rev1=9&rev2=10

--------------------------------------------------

  Disadvantages:
   * cannot assign ACLs to non-existent nodes
   * permissions are stored right inside the content (can be cumbersome for backups, etc.)
-  * does not scale with a high number of users (with permissions on a single resource)
  
  == Principal-based ACLs ==
  A different approach for specifying and storing ACLs is to assign certain principals (users
or groups) a list of nodes that they are allowed or denied to work on. The nodes will be referenced
by paths, and might even include wildcards.
  
- To work with principal-based ACLs, a Jackrabbit-propietary extension to the ACL management
API is required, as the JCR 2.0 API is tied to resource-based ACLs at the moment.
+ To work with principal-based ACLs, a Jackrabbit-propietary extension to the ACL management
API is required.
  
  Advantages:
   * permissions can be assigned to non-existent nodes
   * permissions are stored separately from the content (good for content replication, backup
etc.)
-  * scales better with a high number of users
-  * caching of ACLs is easier, since they naturally are grouped per-principal and JCR sessions
are per-principal as well
  
  Disadvantages:
-  * scales not so good with few users and a high number of permissions for each user (however,
that is a very seldom use case)
   * additional Jackrabbit API has to be used for setting ACLs
  
  == Repository Configuration ==

Mime
View raw message