Problem when using long-lived sessions, ACLs and events together

[jacobilsoe]

Hi.

I have some problems when using long-lived sessions together with ACLs and events in ModeShape 4.1.0.

I have two users, A and B, and a node, N. Initially N is visible to both users.

1. User A changes ACLs on N so that it is visible to A only.

2. User B initiates a long-lived session and adds an event listener like this:

  session.getWorkspace.getObservationManager.addEventListener(eventListener, Event.PROPERTY_CHANGED | Event.NODE_ADDED | Event.NODE_REMOVED, "/", true, null, null, false)

3. User A changes ACLs on N so that it is visible to everyone.

4. User B does not receive events about this change nor any future changes to N even though the node is now visible to B.

If user B sets up the event listener prior to step 1, everything works as expected. ACLs can change back and forth and B is continually notified.

So it seems to be the case that when setting up an event listener, only the nodes that are visible at that point in time, will participate in future events.

Is that expected behaviour?

[hchiorean]

As long as after step 3 user A calls session.save() - i.e. making the policy changes visible - this is not the expected behavior. Once the policy has changed and the node is accessible to the other session (B), this should receive the events.

If you can reproduce this behavior in a test case, feel free to open a JIRA. Thanks.

[jacobilsoe]

I have investigated this a bit further and the change is rejected in org.modeshape.jcr.JcrObservationManager.ChangeSetConverter.shouldRejectChange because the long-lived session does not have read permission to the changed node.

I'll look into reproducing.

[hchiorean]

You're correct: that part of the code validates that the session to which the listener belongs, has READ permissions on the parent path of the change. This is the reason why I asked the previous question: as long as the other session changes the ACLs so that the previous statement is true and saves those changes, they should become accessible to the first session.

[jacobilsoe]

I've tried adding a test in JcrObservationManagerTest but so far I haven't been able to reproduce. Then I wanted to tweak some existing ACL tests but couldn't find any. Are there no ACL tests?

[hchiorean]

See modeshape/AccessControlManagerTest.java at master · ModeShape/modeshape · GitHub or modeshape/JcrNodeTest.java at master · ModeShape/modeshape · GitHub

[jacobilsoe]

I was more thinking tests that involve both ACLs and events. Specifically tests that cover the code around org.modeshape.jcr.JcrObservationManager.ChangeSetConverter.shouldRejectChange.

I just tried downgrading to 4.0.0 and here things work as expected.

[hchiorean]

We don't have any dedicated tests for the combination of Events & ACLs, which is why I asked for a test case in the first place. Using the examples from the previous links it shouldn't be difficult to create such a test case.

Also, you don't necessarily have to create a Unit Test (JUnit) which integrates out-of-the-box with out tests. Any runnable piece of code (e.g. separate maven module/project) is enough, as long as it reproduces the issue.

[hchiorean]

I created & ran a test case based on your description and it runs fine (remember that when dealing with node events permissions are checked on the parent node and while dealing with property events permissions are checked on the owning node). You can see the test case here: https://github.com/hchiorean/modeshape/blob/observation-acl/modeshape-jcr/src/test/java/org/modeshape/jcr/JcrObservationManagerTest.java#L2302

You can use that as a base to try reproducing your issue

[jacobilsoe]

Thanks a lot for taking time to write a test case. I will have a look and try to fit it to the issue I am experiencing.