jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Groups Deny, DefaultAccessManager
Date Tue, 28 Apr 2009 08:47:56 GMT
I have had a look at this now, and unfortunately the ACLTemplate  
(either for principals or normal nodes) is not suitable for extension.

Creating a different version of ACLTemplate will allow a change in the  
storage format and the processing of the ACL, but the critical step is  
compilation of the set of ACE's into a set, filtered for the users set  
of Principals and then compiled into a single bitmap. AFAICT the  
static acl.ACLProvider.collectEntries(node,map) does this for normal  
nodes and pricipalbased.ACLProvider.collectEntries(node,map) for the  
principal based step.

At the moment I think I need to change this behavior so its looking  
more like a replacement ACLProvider to generate a different set of  
compiledPermissions, however it looks like I can combine this in the  
combined.ACLProvider since this also operates on a user principal  
filtered and compiled bitmap (combined from acl.ACLProvider and  

There is a hand built UML diagram of the space that I have been  
creating for this at
(CCS&A Licensed as its the rest of the doc there)

If I could modify the CombinedProvider to work of a list of  
compilePermissions rather than merge all the permissions then I think  
I might be able to add another ACLProvider to the list just for my  
special use cases.

Does that sound like a possible approach to extension ?


On 26 Apr 2009, at 13:56, Lars Michele wrote:

> The AccessControlProviderInterface seems to be a good starting point  
> for
> implementing your own ACLs. But perhaps it would be sufficient for you
> to change the methods in ACLTemplate to evaluate the permission the  
> way
> you want.

View raw message