I think before we embed something into synchronous API requests we should try to define a few more real uses besides just a bucket naming pattern to see if we really need to add something like this. For bucket naming pattern, it could just be a simple property in nifi-registry.properties with a regex to check names against. If we did add some kind of pluggable validator, I don't think these validators should be making authorization decisions, it should be strictly for rules about the content being version controlled. If we are worried about a user version controlling something that interferes with a CI/CD pipeline, that seems to imply our current authorization policy model needs improvement, or it is not being used correctly (i.e. why does a user have write to a bucket they shouldn't be writing to?).
On Wed, Jan 17, 2024 at 8:53 AM Pierre Villard <[email protected]> wrote: > > I do think this would be a good idea. That would provide users of the NiFi > Registry a way to implement custom conditions on what can be versioned or > not based on their requirements. Right now if one has write permissions for > a bucket/flow, you could commit anything as a new version which could > potentially be an issue when using CI/CD pipelines to automate deployments. > > As a side-note, another improvement could be to prevent a flow from being > versioned in the registry if a required rule is violated (I'm talking about > the new feature coming with NiFi 2.0). Just a thought for an additional > improvement. > > Overall I do think that giving options to users for better controlling what > is being versioned is good. > > Le mer. 17 janv. 2024 à 17:13, Simon Bence <[email protected]> a > écrit : > > > Hi, > > > > I recently found the need for custom validation to maintain NiFi Registry > > content. This includes checks such as enforcing naming conventions when > > creating a Bucket and similar usage specific cases. While exploring the > > Registry's codebase, I came across the EventHookProvider, which aligns with > > a similar concept. However, it does not cover the case here due to its > > asynchronous nature and being a "post-event" activity. > > > > Although the EventHookProvider is not suitable for this specific need, I > > find the Event construct and the "whitelist" concept pretty overlapping > > with my objectives. Consequently, I propose the addition of a new type of > > Provider covering for "pre-event" validation, operating in a manner similar > > to the EventHookProvider: a call from the request methods to the set of > > providers but filtered using a whitelist. Similarly to the mentioned > > provider, I believe an implementation capable of executing scripts (akin to > > ScriptEventHookProvider) would be a good starting point, to cover a most > > use cases. > > > > I am keen to hear your opinion on this proposal and welcome any further > > ideas. Thank you for your consideration! > > > > PS.: using the "event" term comes from the already existing > > EventHookProvider. In practice these are the methods of the Registry web > > API. > > > > Regards, > > Bence Simon
