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?
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
