2013/4/22 Jukka Zitting <[email protected]>:
> 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
