You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ie...@tfd.co.uk> on 2009/12/29 16:53:30 UTC
Pluggable Access Control Manager issue?
I notice that
PluggableDefaultAccessManager.isGranted(ItemId id, int permissions)
bypasses some additional logic in
DefaultAccessManager.isGranted(ItemId id, int permissions)
by going direct to
PluggableDefaultAccessManager.isGranted(Path absPath, int permissions)
was that intentional, this might be as a result of the JR 1.6 upgrade. ?
Ian
Re: Pluggable Access Control Manager issue?
Posted by Ian Boston <ie...@tfd.co.uk>.
On 4 Jan 2010, at 10:13, Vidar Ramdal wrote:
>>
>> IMHO PluggableDefaultAccessManager.isGranted should do
>>
>> return super.isGranted(itemId, permissions)
>
> Ah, you're right. I can't remember why I did it like that, but I was
> certainly not aware of the difference between 'permissions' and
> 'actions'. If you'd like to rectify this, please do - although it
> might not be necessary when the method is deprecated.
will do
https://issues.apache.org/jira/browse/SLING-1263
Ian
Re: Pluggable Access Control Manager issue?
Posted by Vidar Ramdal <vi...@idium.no>.
>> On Tue, Dec 29, 2009 at 4:53 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>> I notice that
>>>
>>> PluggableDefaultAccessManager.isGranted(ItemId id, int permissions)
>>>
>>> bypasses some additional logic in
>>> DefaultAccessManager.isGranted(ItemId id, int permissions)
>>>
>>> by going direct to
>>> PluggableDefaultAccessManager.isGranted(Path absPath, int permissions)
>>>
>>> was that intentional, this might be as a result of the JR 1.6 upgrade. ?
> On 3 Jan 2010, at 21:53, Vidar Ramdal wrote:
>> I think it was "intentional" in the sense that ItemId is part of the
>> org.apache.jackrabbit.core package, which is not exported - thus, it
>> would be impossible to implement the AccessManagerPlugin interface in
>> other bundles, if it defined a isGranted(ItemId, int) method.
>> From what I can see, the "additional logic" in
>> DefaultAccessManager.isGranted(ItemId, int) is merely optimization. Or
>> am I missing something?
On Mon, Jan 4, 2010 at 10:37 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> I wasnt thinking so much about the API for AccessManagerPlugin but the method of impl for PluggableDefaultAccessManager
>
> A call to
>
> PluggableDefaultAccessManager.isGranted(ItemId id, int permissions)
> results in
> PluggableDefaultAccessManager.isGranted(Path absPath, int permissions)
> resulting in
> DefaultAccessManager.isGranted(Path absPath, int permissions)
>
> a call to
> DefaultAccessManager.isGranted(ItemId id, int actions)
> results in
> DefaultAccessManager.isGranted(Path absPath, int permissions)
>
> the 2 call stacks are almost identical except the default impl isolates the passed in "actions" from the permissions bitmap.
>
>
> Effectively the pluggable version does
>
> return this.isGranted(this.hierarchyManager.getPath(id), permissions);
>
> assuming the int parameter is permissions
>
>
> and the default version does
>
> int perm = 0;
> if ((actions & READ) == READ) {
> perm |= Permission.READ;
> }
> if ((actions & WRITE) == WRITE) {
> if (id.denotesNode()) {
> // TODO: check again if correct
> perm |= Permission.SET_PROPERTY;
> perm |= Permission.ADD_NODE;
> } else {
> perm |= Permission.SET_PROPERTY;
> }
> }
> if ((actions & REMOVE) == REMOVE) {
> perm |= (id.denotesNode()) ? Permission.REMOVE_NODE : Permission.REMOVE_PROPERTY;
> }
> Path path = hierMgr.getPath(id);
> return isGranted(path, perm);
>
> assuming the int parameter is "actions", although the API javadoc still talks about it as being a limited set of permissions (READ, WRITE and REMOVE only). (NB the method is deprecated in the 1.6 api)
>
>
>
> IMHO PluggableDefaultAccessManager.isGranted should do
>
> return super.isGranted(itemId, permissions)
Ah, you're right. I can't remember why I did it like that, but I was
certainly not aware of the difference between 'permissions' and
'actions'. If you'd like to rectify this, please do - although it
might not be necessary when the method is deprecated.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: Pluggable Access Control Manager issue?
Posted by Ian Boston <ie...@tfd.co.uk>.
On 3 Jan 2010, at 21:53, Vidar Ramdal wrote:
> On Tue, Dec 29, 2009 at 4:53 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>> I notice that
>>
>> PluggableDefaultAccessManager.isGranted(ItemId id, int permissions)
>>
>> bypasses some additional logic in
>> DefaultAccessManager.isGranted(ItemId id, int permissions)
>>
>> by going direct to
>> PluggableDefaultAccessManager.isGranted(Path absPath, int permissions)
>>
>> was that intentional, this might be as a result of the JR 1.6 upgrade. ?
>
> I think it was "intentional" in the sense that ItemId is part of the
> org.apache.jackrabbit.core package, which is not exported - thus, it
> would be impossible to implement the AccessManagerPlugin interface in
> other bundles, if it defined a isGranted(ItemId, int) method.
> From what I can see, the "additional logic" in
> DefaultAccessManager.isGranted(ItemId, int) is merely optimization. Or
> am I missing something?
I wasnt thinking so much about the API for AccessManagerPlugin but the method of impl for PluggableDefaultAccessManager
A call to
PluggableDefaultAccessManager.isGranted(ItemId id, int permissions)
results in
PluggableDefaultAccessManager.isGranted(Path absPath, int permissions)
resulting in
DefaultAccessManager.isGranted(Path absPath, int permissions)
a call to
DefaultAccessManager.isGranted(ItemId id, int actions)
results in
DefaultAccessManager.isGranted(Path absPath, int permissions)
the 2 call stacks are almost identical except the default impl isolates the passed in "actions" from the permissions bitmap.
Effectively the pluggable version does
return this.isGranted(this.hierarchyManager.getPath(id), permissions);
assuming the int parameter is permissions
and the default version does
int perm = 0;
if ((actions & READ) == READ) {
perm |= Permission.READ;
}
if ((actions & WRITE) == WRITE) {
if (id.denotesNode()) {
// TODO: check again if correct
perm |= Permission.SET_PROPERTY;
perm |= Permission.ADD_NODE;
} else {
perm |= Permission.SET_PROPERTY;
}
}
if ((actions & REMOVE) == REMOVE) {
perm |= (id.denotesNode()) ? Permission.REMOVE_NODE : Permission.REMOVE_PROPERTY;
}
Path path = hierMgr.getPath(id);
return isGranted(path, perm);
assuming the int parameter is "actions", although the API javadoc still talks about it as being a limited set of permissions (READ, WRITE and REMOVE only). (NB the method is deprecated in the 1.6 api)
IMHO PluggableDefaultAccessManager.isGranted should do
return super.isGranted(itemId, permissions)
>
> --
> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
> Sommerrogata 13-15, N-0255 Oslo, Norway
> + 47 22 00 84 00 / +47 21 531941, ext 2070
Re: Pluggable Access Control Manager issue?
Posted by Vidar Ramdal <vi...@idium.no>.
On Tue, Dec 29, 2009 at 4:53 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> I notice that
>
> PluggableDefaultAccessManager.isGranted(ItemId id, int permissions)
>
> bypasses some additional logic in
> DefaultAccessManager.isGranted(ItemId id, int permissions)
>
> by going direct to
> PluggableDefaultAccessManager.isGranted(Path absPath, int permissions)
>
> was that intentional, this might be as a result of the JR 1.6 upgrade. ?
I think it was "intentional" in the sense that ItemId is part of the
org.apache.jackrabbit.core package, which is not exported - thus, it
would be impossible to implement the AccessManagerPlugin interface in
other bundles, if it defined a isGranted(ItemId, int) method.
>From what I can see, the "additional logic" in
DefaultAccessManager.isGranted(ItemId, int) is merely optimization. Or
am I missing something?
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070