I believe you are correct Bryan. I hope this information is clarified and makes it into the documentation!
Now, a new wrinkle: as I tried to learn what is going on by trial and error, I had 2 or 3 Nodes on the 'view the data' Access Policy, the Cluster Coordinator/Primary Node and the Node I was using for the UI. I also had myself on the policy. When I attempted to List queue, the Node which was not on the policy was disconnected from the cluster and will not rejoin. I'm not sure how to get it to rejoin short of restarting NiFi. The app.log shows: INFO [Process Cluster Protocol Request-1] 0.a.n.c.p.impl.SocketProtocolListener Finished processing request e0090f82-1871-4edb-b81a-a9380871b811 (type =DISCONNECTION_REQUEST, length=685 bytes) from <Node-not-on-access-policy> in 110 millis INVO [ Disconnect from Cluster] o.a.nifi.controller.StandardFlowService Received disconnection request message from manger with explanation: Failed to process request POST /nifi-api/flowfile-queues/b7763804-af41-1281-0000-0000604c631c/listing-requests INFO [Disconnect from Cluster] o.a.nifi.controller.standardFlowService Disconnecting node. INFO [Disconnect from Cluster] o.apache.nifi.controller.FlowController Cluster State changed from Clustered to Not Clustered .... INFO [Heartbeat Monitor Thread-1-EventThread] o.a.c.f.state.ConnectionStateManager State change: CONNECTED INFO [Curator-Framework-0] o.a.c.f.imps.CuratorFrameworkImpl backgroundOperationsLoop exiting INFO [Heartbeat Monitor Thread-1] o.a.c.f.imps.CuratorFrameworkImpl Starting Those last 3 messages repeat continuously every 5 secs. The Node never successfully rejoins the Cluster. On Mon, Mar 20, 2017 at 4:14 PM, Bryan Bende <bbe...@gmail.com> wrote: > Mark, > > I believe whichever node receives the request from the UI, it will > replicate to the other nodes, and the other nodes will see an incoming > request with two entities (the end user, and the node replicating the > request). Those two entities then need to be authorized to see if they > are allowed to perform the action. > > A similar scenario in stand-alone mode would be if another system > passed along a proxied user in the X-ProxiedEntitiesChain header, then > NiFi would see the identity of the system making the request, as well > as the proxied user, and would have to authorize them both. > > Did you happen to be using the UI from the node that was the cluster > coordinator? > > If so maybe all of your list/clear operations succeeded with only that > node in the policies, but if you went to the UI from another node > maybe it wouldn't work? > > -Bryan > > On Mon, Mar 20, 2017 at 3:53 PM, Mark Bean <mark.o.b...@gmail.com> wrote: > > I observed that only the Cluster Coordinator Node (which also happens to > be > > the Primary Node) needed to be on the Access Policy, not all Nodes. > > > > More to the point, why do the Node(s) themselves need to be on the > policy? > > When not Clustered, the machine does not need to be on the policy. > Perhaps > > this is necessary in a Cluster because one Node propagates the request > the > > remaining Nodes.. so it is the Node making the request, not the > individual > > User? > > > > Looking for clarification. > > > > Thanks, > > Mark > > > > > > On Mon, Mar 20, 2017 at 3:45 PM, Arpit Gupta <ar...@hortonworks.com> > wrote: > > > >> Hi Mark > >> > >> One needs to make sure all nodes in your cluster are added to the policy > >> and not just the cluster coordinator. > >> > >> -- > >> Arpit > >> > >> On Mar 20, 2017, at 12:05 PM, Mark Bean <mark.o.b...@gmail.com<mailto: > >> mark.o.b...@gmail.com>> wrote: > >> > >> In order to successfully 'List queue', a user must be part of the 'view > the > >> data' access policy. Similarly, in order to successfully 'Empty queue', > a > >> user must be part of the 'modify the data'. However, in a Cluster > >> configuration, it appears the Cluster Coordinator must also be in the > >> relevant policy in order to be successful. > >> > >> Is this expected behavior? > >> > >> Apache NiFi 1.1.2 > >> > >> >
