On 16 Sep 2009, at 18:37, Bertrand Delacretaz wrote:
Hi,
On Wed, Sep 16, 2009 at 10:09 AM, Ian Boston <[email protected]> wrote:
On 16 Sep 2009, at 18:04, Vidar Ramdal wrote:
.... What if we alter the AMP interface and let the boolean
methods
(isGranted, canRead) return Booleans instead? That way, the AMP
could
return null to signalize that handling should fall back to
DefaultAccessManager....
...will do, jira -> patch -> review -> commit as usual. I'm wont
just trample
of the api....
IIUC you're going to change the AccessManagerPlugin interface?
If yes I'd suggest holding an explicit VOTE here, about the suggested
changes - if only to make sure people who use it are aware of it.
-Bertrand
Agreed,
The patch at SLING-1110 will change the API's and needs review, and a
vote.
However, after sleeping on the issue, I am not certain that the
changes achieve the desired results.
the AMP can express an opinion at the item level, but in order for it
to be really useful I think it needs to express an opinion at the ACL
level. I will try and explain in as few words as possible.
In the DefaultAccessManager (DAM) the effective ACL, bound to the set
of principals associated with the user is constructed by a
hierarchical search, if the AMP desires to make decisions compatible
with principal bound ACL's (IMHO, it does) then it will need to be
able to construct the ACL.
Consequently the patch in SLING-1110 is moot, although it allows the
AMP to delegate to the DAM, it wont remove the need to duplicate the
ACL construction code in the DAM, and so the patch doesn't actually
address the fundamental use case, which IMHO is to plug in access
control customizations on a user-item basis compatible with the DAM
and ACL based access control in Jackrabbit 1.5 and critically in
Jackrabbit 2.
At the moment this issue is, "do nothing and think again"
Ian
