Github user mcgilman commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2703#discussion_r191444067
--- 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 --
@markobean The summary concept was introduced for performance reasons [1].
The summary represents the details required to render a row in the table. Some
events can contain a lot of details (many children/parents UUIDs, flowfile
attributes, etc) which was causing the table to load extremely slowly. The
fully populated event (not summary) is returned once a dialog is opened and
those details can be rendered.
My suggestion would be to not modify the summary concept. Returning more
details in the summary for users with access to the event but not the data will
begin to regress NIFI-1135. Artificially withholding event fields they should
have access to also doesn't seem right.
Since we're moving to this super granular approach, I would recommend the
following.
1) `createProvenanceEventDto(...)` is only invoked once we know the user
has permissions to the event.
2) Within `createProvenanceEventDto(...)` I would check if the user is
allowed to access that component to populate the component details. If the user
does not have access, I would use the ID in place of the name and 'Processor'
in place of the fully qualified class name (for Processors).
3) Within `createProvenanceEventDto(...)` I would check if the user is
allowed to access the component's data to populate the attributes and content
details. If the user does not have access, I would leave those fields unset.
This should retain the summary concept while introducing the granular
approach we're looking for. Thoughts?
[1] https://issues.apache.org/jira/browse/NIFI-1135
---
