Behavioral Changes

Learn about the change in behavior in this version of CFM 2.1.1.

DOCS-9193: After upgrade, update header value for X-ProxiedEntitiesChain

If you are upgrading from CFM 2.0.4 to CFM 2.1.1, then you are upgrading from Apache NiFi version 1.11.4 to 1.13.2. In this case, after you upgrade, if you want an authorized proxy to make a web request on behalf of another authenticated user, then you must enclose the X-ProxiedEntitiesChain header value in < >.

Previous behavior:

There was no need to add an outermost < > to the X-ProxiedEntitiesChain header value.

New behavior:

The handling of the X-ProxiedEntitiesChain header for secure proxy requests is now more strict, requiring the outermost < > in the value.

For example, a value of %{SSL_CLIENT_S_DN} (Apache httpd) or $ssl_client_s_dn (NGINX) that was previously valid must now be formatted as: <%{SSL_CLIENT_S_DN}> or <$ssl_client_s_dn>.

For other migration information, review the Apache NiFi Migration Guidance to be aware of changes made between versions and the impact they may have on your existing dataflows.

DOCS-8537: Granular Restricted Component Policy in Ranger

You can now use the Ranger policy /restricted-components to differentiate permissions between processors. For instance, previously, the /restricted-components/read-filesystem policy covered both a processor like FetchFile and a processor like FetchHDFS.

In this release, you can differentiate between the processors by specifying the following levels of the /restricted-components policy for Hadoop related processors:

• /restricted-components/read-distributed-filesystem
• /restricted-components/write-distributed-filesystem

For more information, see NiFi Restricted Components.