Page History

...

• Migrating from 1.13.x to 1.14.0 (unreleased)
  • The nifi-storm-spout module was removed from nifi-external and will no longer be provided in source or binary form. Users requiring the module can obtain the source and binary from 1.13.x and prior releases.
• Migrating from 1.13.x to 1.13.1
  • Removed the following nar(s) from the convenience build.  They are still built and made available in maven repositories so you can add them to your deployment lib folder and use them if you like.  They include; nifi-grpc-nar
• Migrating from 1.12.x to 1.13.x
  • HTTP access to NiFi by default is now configured to accept connections to 127.0.0.1/localhost only.  If you want to allow broader access for some reason for HTTP and you understand the security implications you can still control that as always by changing the 'nifi.web.http.host' property in nifi.properties as always. That said, please take the time to configure proper HTTPS.  We offer detailed instructions and tooling to assist.
  • Removed the following nar(s) from the convenience build.  They are still built and made available in maven repositories so you can add them to your deployment lib folder and use them if you like.  They include; nifi-livy-nar, nifi-livy-controller-service-api-nar, nifi-kafka-0-11-nar, nifi-beats-nar, nifi-ignite-nar
  • Both embedded and external ZooKeeper connections can now be secured with TLS. The administration guide contains configuration examples to enable this feature. For embedded ZooKeeper, it will require setting the secureClientPort value in zookeeper.properties. There are also new properties defined in the admin guide, including nifi.zookeeper.client.secure which tells NiFI to use a secure client to access a secured ZooKeeper, and nifi.zookeeper.security.* properties to define separate key/trust stores if required. By default the nifi.security.* values will be used to establish trust, but if nifi.zookeeper.security.* values are defined, these will be used instead.
  • The handling of the X-ProxiedEntitiesChain header for secure proxied requests is now more strict, requiring the outermost <, >. For example, whereas a value of %{SSL_CLIENT_S_DN} (Apache httpd) or $ssl_client_s_dn (NGINX) was previously valid, <%{SSL_CLIENT_S_DN}> or <$ssl_client_s_dn> must now be used.

...