mcgilman opened a new pull request, #11247:
URL: https://github.com/apache/nifi/pull/11247

   …e descedent components when authorizing bulletins.
   
   # Summary
   
   [NIFI-15939](https://issues.apache.org/jira/browse/NIFI-15939)
   
   `StandardNiFiServiceFacade#getProcessGroupBulletins` resolves each 
bulletin's source through `AuthorizableLookup` to decide whether the current 
user has READ on it. `AuthorizableLookup` is backed by the standard component 
DAOs, all of which walk the `FlowManager`'s root process group. Bulletins 
emitted by components that live inside a Connector's managed flow are rooted at 
the connector node (whose authorizable parent chain terminates at the connector 
via `ProcessGroup#setExplicitParentAuthorizable`), not under the framework's 
root group, so every lookup misses with `ResourceNotFoundException` and the 
bulletin entity is returned with `canRead = false`. The connector canvas 
suppresses bulletin icons whenever `canRead = false` (because the un-authorized 
entity carries no payload), so users never see bulletins for components inside 
their connectors — even though they have READ on the connector itself.
   
   This change makes `authorizeBulletin` aware of the owning `ProcessGroup` so 
it can resolve a bulletin's source via the live group hierarchy first, falling 
back to `AuthorizableLookup` for sources that are not addressable via a 
`ProcessGroup` (controller-scoped reporting tasks, flow analysis rules, 
registry clients, parameter providers, the flow controller, and connectors 
themselves).
   
   ### Behavior
   
   - A new package-private overload `authorizeBulletin(Bulletin bulletin, 
ProcessGroup group)` is introduced. The original `authorizeBulletin(Bulletin)` 
is preserved as a thin delegate that passes `null`, so existing callers behave 
identically.
   - Source resolution moves into a new `resolveBulletinAuthorizable(sourceId, 
type, group)` helper. When `group` is non-null it first walks the group via the 
`findX` APIs (`findProcessor`, `findInputPort`, `findOutputPort`, 
`findRemoteProcessGroup`, `findControllerService(true, true)`, 
`findProcessGroup` — with a self-id short-circuit that returns the group 
itself). On a hit, the resolved `Authorizable`'s parent chain is the 
connector's chain, so a READ check against the connector node grants READ on 
its inner bulletins. On a miss, or for source types that are not addressable 
via a `ProcessGroup`, it falls back to the existing `AuthorizableLookup` switch.
   - `authorizeBulletin` now also short-circuits to `false` if the resolver 
returns `null`, in addition to the existing `ResourceNotFoundException` 
short-circuit.
   - `getProcessGroupBulletins` is updated to pass the owning `ProcessGroup` 
into `authorizeBulletin`. No other callers of `authorizeBulletin(Bulletin)` are 
changed; their behavior is preserved by the no-arg delegate.
   
   ### Test coverage
   
   Three new unit tests in `StandardNiFiServiceFacadeTest` cover the resolution 
matrix end-to-end through `updateProcessGroup` so they exercise the real 
bulletin pipeline:
   
   - 
`testUpdateProcessGroup_BulletinAuthorizedViaGroupLookupWhenAuthorizableLookupMisses`
 — `AuthorizableLookup#getProcessor` throws `ResourceNotFoundException`, the 
group's `findProcessor` returns an approving authorizable, and `canRead` is 
`true`.
   - 
`testUpdateProcessGroup_BulletinAuthorizationFallsBackToAuthorizableLookupWhenGroupLookupMisses`
 — group's `findProcessor` returns `null`, the fallback 
`AuthorizableLookup#getProcessor` returns an approving authorizable, and 
`canRead` is `true`.
   - `testUpdateProcessGroup_BulletinDeniedWhenNeitherLookupResolvesSource` — 
both lookups miss and `canRead` is `false`.
   
   ### Compatibility
   
   - The public `NiFiServiceFacade` surface is unchanged.
   - `authorizeBulletin(Bulletin)` is preserved as a delegate, so all other 
callers continue to authorize against the global `AuthorizableLookup` exactly 
as before.
   - The group-scoped path narrows `false → true` only for bulletins whose 
source is reachable from the supplied `ProcessGroup` and whose authorizable 
parent chain grants READ to the current user — the same READ check, just 
performed against the source's actual authorizable parent instead of failing to 
resolve the source at all.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to