2013/4/22 Jukka Zitting : > Hi, > > A question especially to Angela, but perhaps of interest also to others. > > Consider a content structure where a user has read access to a > /foo/bar node, but not its parent, the /foo node. Additionally, the > user also has read access to a /foo/baz property. In such a case the > the following statements should work: > > session.getNode("/foo/bar"); > session.getProperty("/foo/baz"); > > But the following statement would throw an exception: > > session.getNode("/foo"); > > So far so good. Now for the question: > > Given that the "bar" node and the "baz" property are visible, should > it be possible to acquire Node- and PropertyIterators from the "/foo" > parent, that contain those items? In other words, should the following > statements (or their variants) work: > > session.getNode("/foo").getNodes(); // contains "bar" > session.getNode("/foo").getProperties(); // contains "baz" > > Intuitively I'd say that these should *not* work, i.e. children of a > non-accessible parent can't be iterated, only accessed directly by > path. I had recently thought about something similar, in another context. Specifically, should the following queries return "bar" or not? SELECT * FROM [nt:base] AS n WHERE ISDESCENDANTNODE(n, '/foo') Or SELECT * FROM [nt:base] AS n WHERE ISCHILDNODE(n, '/foo') The behaviour of the above might be worth considering, as far as backwards-compatibility is concerned. Cheers Lukas > That's how the post-OAK-709 NodeState contract is defined, but the > current SecureNodeState implementation works differently. Before > fixing the SecureNodeState implementation I'd like to verify that my > interpretation of access rights is correct and we won't run in to > backwards compatibility issues with it. > > BR, > > Jukka Zitting