On 3/2/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On 2/28/07, Marcel Reutegger <[EMAIL PROTECTED]> wrote:
> according to the spec Item.getPath() is different in this respect. that is,
you
> can get the path of an item even though an ancestor of an item is not
'visible'
> to you. I put visible in quotes because at least the name of the ancestor
> where a session does not have read right is disclosed.
Looking deeper into this I find it curious that AccessDeniedException
is declared for Item.getParent() and Item.getAncestor(), but not for
things like Session.getItem(). I assume this is because throwing an
AccessDeniedException from Session.getItem() would actually expose the
fact that such an item exists, and thus it is more correct to throw a
PathNotFoundException. However, with Item.getParent() or
Item.getAncestor() the existence of the parent or ancestor node is
already known, so throwing an exception doesn't seem to serve any
security purpose.
The only thing being protected is that the client will not have a
reference to a parent or ancestor node. I could always construct a
custom Node instance myself that would act just like such a parent or
ancestor node would, throwing AccessControlExceptions for all attempts
to access property, child node, or metadata information. How would
such an instance differ from something that Item.getParent() or
Item.getAncestor() can't return?
it wouldn't be compliant with the spec i guess ;)
you wouldn't expect e.g. getPrimaryType() throwing an AccessDeniedExcpetion.
the jsr 170 eg's rationale for the different behaviours of Session.getItem
and Item.getParent wrt access control is as you assumed correctly:
Session.getItem throws a PathNotFound if access is denied. Item.getParent
otoh throws an AccessDeniedException in same situation since the existence
of the requested item is evident. once you have e.g. a reference to a Node
instance you should imo be able to retrieve its primary/mixin node types.
cheers
stefan
> well, I guess this is just a detail...
An interesting detail, as it exposes some of the underlying access
control assumptions in JCR... Perhaps a topic to take up at the
JSR-283 EG.
BR,
Jukka Zitting
