@whoknows  Apache NiFi 2.0.0-M1 requires Java 21 and utilizes Jetty 10.  This results in needing to comply with the SNI specification.   So the URL used to access your NiFi can not use an IP address and the hostname used must match a hostname found in the SAN entries list with the NiFi's configured keystore PrivateKeyEntry. Apache NiFi 2.0 out-of-the-box will generate a keystore and truststore.  The keystore will contain a PrivateKeyEntry with a SAN entry for localhost and the server hostname. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Zifo1  Welcome to the community.... The Single User Authorizer is not a full featured authorization provider. It was only added to Apache NiFi so that out-of-the-box NiFi would be able to start securely easily for evaluation purposes.  It does not provide a mechanism for creating additional authorizations for other identities such as other NiFi instances. In order to support authorizing additional user/client identities against various NiFi policies, you'll need to switch to using a production ready authorizer like the "managed-authorizer". A typical example configuration would look like this: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#file-based-kerberos-authentication This setup uses the File-user-group-provider and file-access-policy-provider with the managed -authorizer. Now you could configure your single user provider identity as the "Initial User Identity 1" in the file-user-group-provider and as the "initial admin identity" in the file-access-policy-provider.  This would setup the needed admin policies for this user identity you need.   Note: Keep in mind that these providers will only generate the authorizations.xml and users.xml files the first time NiFi is started with this configuration. So if you set the above initial user and initial admin identities wrong, you'll need to fix config, delete these two files and start NiFi again so they are created again. Above does nothing with authentication since you are still using the single user authentication.  With this default authentication provider you can only authenticate with the single user identity or using a clientAuth certificates (which may also be challenging with default truststore your out-of the-box NiFi uses).   Authentication via a mutualTLS exchange is how Nifi node to node communications work and NiFi site-to-Site.  In order for mutual TLS exchange to be successful there must be mutual trust of the certificate exchanged.  So if one NiFi's certificate is not trusted by the other NiFi's truststore, authentication will not be possible.  So you may need to add additional trustedCertEntries (public certs) to both your NiFi's truststores before you'll be able to successfully negotiate the MutualTLS exchange/handshake. All the available authentication providers offered are documented here: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#user_authentication Aside from the single-user authentication provider, all other providers rely on some external source.  Apache NiFi does not offer a multi-user local authentication provider. I know this is a lot of info thus far, but should provide you the path to a slightly more production ready NiFi that will open up the ability to use additional features not available with the out-of-the-box setup. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Coordinador  You could upgrade your MongoDB to a newer version. Another option you may try is to add the Apache NiFi 1.16 *mongo* nars to your Apache NiFi 1.22 custom extension folder: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#autoloading-processors This will make both the 1.16 and 1.22 versions of the mongo processor available for use in your 1.22 Apache NiFi. The Mongo Driver has been updated numerous times between 1.16 and 1.23: https://issues.apache.org/jira/browse/NIFI-9886 https://issues.apache.org/jira/browse/NIFI-10557 https://issues.apache.org/jira/browse/NIFI-11419 https://issues.apache.org/jira/browse/NIFI-11856 If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@SAMSAL  The managed Authorizer uses the file-access-policy-provider (generates the authorizations.xml if it does no already exist) and then a user-group-provider.  In your case that would make most sense to be the ldap-user-group-provider.  You may also want to use the Composite-configurable-user-group-provider (configure it with ldap-user-group-provider and file-user-group-provider).  Having both a file based provider and ldap provider allows sycning of ldap users and groups  form ldap automatically as well as the file provider allowing you to manually add non ldap user/client identities for authorization as well.    Non ldap client/user identities might be certifcate based clients like other NiFi nodes/instance, etc.. Within the file-access-policy-provider you define the initial admin identity. That user identity could be set to your ldap user account identity.  Then on first start up with managed provider, it generates the authorizations.xml file seeded with the policies necessary for that initial admin user identity to act as admin.  So you could skip the single-user-provider step. Matt ... View more

@ChuckE  Plus 1 on @SAMSAL post.  I also had no problem with it working on my CFM 2.1.5.3 SP3 (Based off Apache NiFi 1.18 with many bug fixes from 1.19 - 1.20)      Thanks, Matt ... View more

@Rohit1997jio  You could use the RetryFlowFile processor for this use case.  You will feed the "failure" relationship via a connection to the RetryFlowFile processor.  The RetryFlowfile processor will continue to route the FlowFile back to PublishKafka using the "retry" relationship until maximum number of retries configured has been exceeded.  After max retries has been reached the FlowFile would instead route to the "retries_exceeded" relationship which you can connect to a LogMessage processor.  The logMessage processor would then auto-terminate the "success" relationship. The challenge you have here is  your requirement to retry once per hour for 24 hours.  You could set the penalty duration in the PublishKafka to 1 hour.  This means that FlowFile routes to the "failure" relationship would get penalized for 60 mins.  The RetryFlowFile would not consume that FlowFile from input connection until penalty duration ended.  Then configure your number of retries in the RetryFlowFile processor to 24.  Be careful with setting queue size to 250 on the failure connection.  If you reach 250 queued on the failure relationship, it will trigger backpressure on the PublishKafka processor meaning the publishKafka processor would not get scheduled again until that backpressure is gone. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@lafi_oussama  If I am understanding correctly, this sounds like expected behavior.  You are writing a NiFi Expression Language (NEL) statement to an attribute via your python script so it is not being evaluated by the NEL process. I am not clear on why you are using a python script here anyway. As i understand your use case: 1. NiFi is ingesting files with various filenames. 2. Depending on the filename, you want to add an attr1 attribute to the FlowFile with a specific path value 3. If the filename does not match and value, you want to add an attr1 attribute to FlowFile with value "notfind". This use case can easily be handled by a single UpdateAttribute processor through the use of the "Advanced" functionality without needing to develop and manage a python script. The "Advanced" functionality  works like an If/Then/Else. Would look something like this: Outside the "Advanced" UI is the Else.  Any dynamic attributes add here are added to FlowFile only if the same attribute was NOT added by a rule in the "Advanced" section. So here you set attr1 = "notfind". Inside the "Advanced" section you create one or more rules.  Each rule has a Conditon (If) and an Action (then) sections.  If the condition NEL resolves to "true" then actions are applied to FlowFile.  So you set up a rule for each flowfile filename type. If none of teh rules match then the default attr = notfind is set. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@lafi_oussama  I am not clear in your ask here. I assume you are using the above NiFi Expression language (NEL) statement in an Update Attribute processor? Assuming the NiFi FlowFile has a filename=blah-OD_NCE-2023.gz ${filename:find('OD_NCE.*.gz') <-- resolves to true :ifElse("/isod/brt_fin_fd_OD_NCE_pipe_sep","notfind")} <-- since above is "true", the if else function would return "/isod/brt_fin_fd_OD_NCE_pipe_sep" and that woud be assigned to the "attr1" attribute on the outbound FlowFile. If your filename does not match your java regular expression "OD_NCE.*.gz" (result in false) would result in attr1 = notfind So I am not clear on what you are asking for: I want to have the value of expression not the string Can you provide an example of what you want to be assigned to FlowFile Attribute "attr1" and what you are actually getting? This info is also not clear to me: I read this expression from file and after this I convert the content to attributes How are you reading expression from file?  What exactly are you reading? Why are you converting FlowFile content to FlowFile attributes?  FlowFile Attributes reside within the NiFi's JVM heap.  So you'll want to avoid this unless absolutely necessary and when you so, only extract the minimum needed. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

@zIfo  The default Single-User-Authorizer (Authorization) and Single-user-provider (authentication) are not intended for production use.  These were added as of  Apache NiFi 1.14 to facilitate a secure out-of-the-box NiFi startup for evaluation and testing.   They provide very basic authentication and authorization. Single user with complete and full access to everything.  So by using this default provider you have no ability to support multiple users with very granular levels of authorization.  The Token on the NiFi server side should expire after 8 hours.  The JWT token stored in the browser may be around longer. You did not share the version of Apache NiFi you have installed, but perhaps the following explains what you are experiencing : https://issues.apache.org/jira/browse/NIFI-9049 But to support NiFi Clusters and NiFi multi-tenant authentication and authorization, you should move to a production ready authentication provider (LDAP commonly used) and authorizer (Managed authorizer commonly used). If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more