hi jukka
i would expect the same... in particular since
> session.getNode("/foo").getNodes(); // contains "bar"
> session.getNode("/foo").getProperties(); // contains "baz"
session.getNode("/foo") should never work if you are not
allowed to retrieve that node and thus you don't have the
means to retrieve the child collection from that node.
kind regards
angela
On 4/22/13 9:47 AM, Jukka Zitting wrote:
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.
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
