[
https://issues.apache.org/jira/browse/JCR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406993#comment-13406993
]
Bart van der Schans commented on JCR-3364:
------------------------------------------
Hi Thomas,
The problem is that in the example I gave both session have a different
hierarchy in their transient sessions. Before there is any save/sync, both
views are "correct".
Consider when the paths are a bit deeper:
- /a1/a2/aa
- /b1/b2/
sess1:
move a2 to /b1/b2
results in the transient view of sess1:
- /b1/b2/a2/aa
- /a1
sess2:
move b1 to /a1/a2/aa
results in the transient view of sess2:
- /a1/a2/aa/b1/b2
- /
At this point sess1 has pulled b2 in its transient state since it's modiefied,
but (without my previous fix) b1 is never read by sess1 and not part of the
transient state.
Now consider that sess2 does a save. There is nothing that prevents this save
and the new persistent hierarchy is sess2's view. At this point the parent of
b1 is node aa.
Now sess1 does a getPath() on node "aa". This results in fetching the parent
nodes for finding out the path and now it's broken: aa > a2 > b2 > b1 (fetch
from the shared/persistent layer) > aa > a2 > b2 .... etc. etc. and a loop is
created. Of course if you would save this you would only persist the problem.
So in my opinion, moving a node to a new target means that the session needs to
create it's own transient view of the hierarchy of the target location.
The problem you ran into is that you can't read a parent node. In the example
about that would be node b1 for sess1. I'm not sure if we can create a "hidden"
transient state for the b1 node by setting the permission check to false in
sess1. It might just popup somewhere in a cache.
Can you check in your use case what actually happens if you create a quick hack
so that the createTransientParentStates method somehow calls the createItemData
with the permission check set to false?
Bart
> Moving of nodes requires read access to all parent nodes of the destination
> node
> --------------------------------------------------------------------------------
>
> Key: JCR-3364
> URL: https://issues.apache.org/jira/browse/JCR-3364
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.2.12, 2.4.2, 2.5
> Reporter: Thomas März
>
> Before JCR-3291 was fixed, Session#move(String, String) could move nodes
> without having read-access to the whole tree.
> - Deny jcr:read on /home and grant jcr:all on /home/users/usera to usera
> - Move nodes from /home/users/usera/from to /home/users/usera/to with usera's
> session
> - AccessDeniedException is thrown
> http://article.gmane.org/gmane.comp.apache.jackrabbit.user/18892
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
