Github user mcgilman commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2703#discussion_r192492247
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/controller/ControllerFacade.java
---
@@ -1359,7 +1363,12 @@ public ProvenanceEventDTO getProvenanceEvent(final
Long eventId) {
} else {
dataAuthorizable =
flowController.createLocalDataAuthorizable(event.getComponentId());
}
- dataAuthorizable.authorize(authorizer, RequestAction.READ,
NiFiUserUtils.getNiFiUser(), attributes);
+ // If not authorized for 'view the data', create only
summarized provenance event
--- End diff --
The original JIRA called to make this more granular because using the data
policies was too blunt. In the PR as-is, for each event it appears that we
authorize the event and then authorize the data policies twice. We are
authorizing the data policy to determine if we should summarize and then again
to determine if replay is authorized. The replay portion is not changed/new in
this PR but is an area for improvement we could make now.
Since we're taking this more granular approach I agree with your originally
filed JIRA to add the additional component based check. This shouldn't
introduce too much additional cost. The component checks do not consider flow
file attributes and the results should be easily cached.
Another improvement that I didn't call out specifically above, is that we
really only need to check the data policies if we are not summarizing. Whether
the user is approved for data of a component would only be relevant if we were
returning the fully populated event.
In order to return the summary, we only need to check the policies for the
event and the component. Like the component policies, I don't _think_ the flow
file attributes would need to be considered for the event policies. I believe
the attributes would only need to be considered for the data policies where we
are actually returning the attributes and content. This should help with some
of the performance concerns regarding frequent authorization.
---
