Sure! Point taken. It would be nice to implement against the JCR API
itself at this stage. Delivery pressures directs at a decision now. So
will go with the JR way and will refactor (+ migrate :-() to the JCR->JR
way.
-----Original Message-----
From: Angela Schreiber [mailto:anchela@day.com]
Sent: 14 August 2008 14:36
To: users@jackrabbit.apache.org
Subject: Re: Node level access rights
> I am using the JR current trunk. Reinventing yet another wheel when
> smarter people are contributing wisely is hardly my approach. I will
> check out the trunk implementation. Thank you very much!
but please note, that JSR 283 is not finalized yet
and the access control section is going to change
again... work in progress...
angela
> -----Original Message-----
> From: Torgeir Veimo [mailto:torgeir@pobox.com]
> Sent: 14 August 2008 13:18
> To: users@jackrabbit.apache.org
> Subject: Re: Node level access rights
>
>
> On 14 Aug 2008, at 17:38, Boni Gopalan (BioImagene) wrote:
>
>> What is the best approach to define access rights and to control
>> access
>> at Node Level?
>
>
> Options;
>
> 1. wait for a jackrabbit release with the new JSR 283 access control
> API (JR 1.5), or
> 2. implement your own;
>
> - create acl mixin node types (subclass mix:referenceable) that can be
> attached to any node type
> - at startup query for all such node types, put them in a hashmap
> cache keyed on their uuid
> - implement a listener that listens to any change to nodes that have
> this node type which updates said cache
> - implement an access controll handler that checks operations on
> nodes, whenever a change is being done to a node which has the node
> type above, check if the operation in question is allowed, by fetching
> the node from cache.
>
> 3. use JR current trunk. The access control api implementation was
> committed in revision 638834.
>