I don’t think this extends to the general case, but in this instance, I support Bryan’s first suggestion. The RestrictedSSLContextService interface will extend the SSLContextService interface, and the StandardRestrictedSSLContextService class can implement that interface and extend StandardSSLContextService and just override the methods related to getting the supported protocols. I think this is the cleanest solution for the issue.
Thanks for doing this, Mike. Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Aug 14, 2017, at 12:09 PM, Bryan Bende <[email protected]> wrote: > > Hi Michael, > > Generally processors are supposed to only know about an interface for > the service, and then the framework makes the implementations of that > interface available. So the processors shouldn't really know which > specific implementations are available. > > I think there are a couple of things that could be done... > > You can make a new interface called RestrictedSSLContextService that > extends SSLContextService, and then have an implementation like > StandardRestrictedSSLContextService... then make your customized > ListenHTTP processor rely only on the new interface > (RestrictedSSLContextService). > > Another option might be to do something involving custom validate (as > you mentioned)... If the SSLContextService interface had a method to > return a list/array of the supported protocols, then a processor could > use those values in a custom validate to make sure that a service with > the required protocols was selected. You are right that they would > still see all the services in the drop-down, but the processor would > be invalid and unable to be started until selecting the appropriate > service, and they'd see the validation message about what was wrong. > > A final option, although not something that is currently possible, > might be to leverage the security model... If you could restrict who > could create a specific type of component, meaning something like > "admin has create permissions on StandardSSLContext from > nifi-standard-nar", then you could set it up so that regular users can > create your restricted service and only admins (or maybe no one) can > create the other kind. > > -Bryan > > > On Mon, Aug 14, 2017 at 11:35 AM, Michael Hogue > <[email protected]> wrote: >> All, >> >> I'm in the process of making some changes to a processor which exposes a >> controller service with several implementations. However, I only want to >> allow a particular implementation for the processor, but i've not found a >> clean way to do this. The rationale behind wanting to do this can be found >> in the conversation on PR #1986 [1]. In short, I've written a >> RestrictedSSLContextService that allows only a specific set of SSL >> algorithms to be chosen. I want to change ListenHTTP to allow only that >> implementation and not the StandardSSLContextService. >> >> PropertyDescriptor builders have a method >> identifiesControllerService(clazz) which allows you to dictate which >> interface the controller service must implement. This is great because it >> should allow me to specify an explicit implementation i'd like to force the >> processor to allow. The problem with this is that it necessitates an >> additional dependency on a non-API module, which i believe is ill-advised. >> It actually results in multiple identical controller service entries when >> you go to configure the controller service in the UI due to nar service >> loading. This is probably a bad thing. >> >> I've looked across the code base and don't really see an example of >> restricting controller service options to specific implementations if you >> only want to allow a subset, for example. Adding a validator wouldn't >> really work either since the UI would still allow you to choose a >> controller service you don't want to allow. My question to those more >> familiar with the codebase is whether there's an obvious way to approach >> this or if there needs to be significant changes to allow it. >> >> Thanks, >> Mike >> >> [1] https://github.com/apache/nifi/pull/1986
signature.asc
Description: Message signed with OpenPGP using GPGMail
