[jira] [Commented] (NIFI-11086) NiFi Registry keystore passwd change
[
https://issues.apache.org/jira/browse/NIFI-11086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680891#comment-17680891
]
Nathan Gough commented on NIFI-11086:
-
I was able to verify the issue does occur, though I noted a different exception:
{code:java}
2023-01-25 23:20:04,933 WARN [main] o.apache.nifi.registry.jetty.JettyServer
Failed to start web server... shutting down.
org.apache.nifi.security.ssl.BuilderConfigurationException: Key Manager
initialization failed
at
org.apache.nifi.security.ssl.StandardSslContextBuilder.getKeyManagers(StandardSslContextBuilder.java:120)
at
org.apache.nifi.security.ssl.StandardSslContextBuilder.build(StandardSslContextBuilder.java:55)
at
org.apache.nifi.registry.jetty.connector.ApplicationServerConnectorFactory.buildSslContext(ApplicationServerConnectorFactory.java:147)
at
org.apache.nifi.registry.jetty.connector.ApplicationServerConnectorFactory.(ApplicationServerConnectorFactory.java:74)
at
org.apache.nifi.registry.jetty.JettyServer.configureConnectors(JettyServer.java:150)
at
org.apache.nifi.registry.jetty.JettyServer.(JettyServer.java:101)
at org.apache.nifi.registry.NiFiRegistry.(NiFiRegistry.java:114)
at org.apache.nifi.registry.NiFiRegistry.main(NiFiRegistry.java:168)
Caused by: java.security.UnrecoverableKeyException: Cannot recover key
at
java.base/sun.security.provider.KeyProtector.recover(KeyProtector.java:304)
at
java.base/sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:162)
at
java.base/sun.security.util.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:91)
at java.base/java.security.KeyStore.getKey(KeyStore.java:1050)
at
java.base/sun.security.ssl.SunX509KeyManagerImpl.(SunX509KeyManagerImpl.java:141)
at
java.base/sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:64)
at
java.base/javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:275)
at
org.apache.nifi.security.ssl.StandardSslContextBuilder.getKeyManagers(StandardSslContextBuilder.java:118)
... 7 common frames omitted
2023-01-25 23:20:04,933 INFO [Thread-0] org.apache.nifi.registry.NiFiRegistry
Initiating shutdown of Jetty web server...
2023-01-25 23:20:04,933 INFO [Thread-0] org.apache.nifi.registry.NiFiRegistry
Jetty web server shutdown completed (nicely or otherwise).{code}
This is something we could fix directly for this one issue in the NiFi Registry
Client, or maybe there's a way to make this common with NiFi. I note that
similar 'getSslContext()' methods exist in other places eg the SiteToSiteClient.
> NiFi Registry keystore passwd change
>
>
> Key: NIFI-11086
> URL: https://issues.apache.org/jira/browse/NIFI-11086
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
>Affects Versions: 1.19.1
>Reporter: Anders
>Priority: Minor
>
> After upgrading NiFi Registry from 1.17.0 to 1.19.1, it stopped working with
> the following logged stacktrace:
> {code:title=nifi-registry-app.log}
> 2023-01-20 09:09:50,530 WARN [main] o.apache.nifi.registry.jetty.JettyServer
> Failed to start web server... shutting down.
> org.apache.nifi.security.ssl.BuilderConfigurationException: Key Manager
> initialization failed
> at
> org.apache.nifi.security.ssl.StandardSslContextBuilder.getKeyManagers(StandardSslContextBuilder.java:120)
> at
> org.apache.nifi.security.ssl.StandardSslContextBuilder.build(StandardSslContextBuilder.java:55)
> at
> org.apache.nifi.registry.jetty.connector.ApplicationServerConnectorFactory.buildSslContext(ApplicationServerConnectorFactory.java:147)
> at
> org.apache.nifi.registry.jetty.connector.ApplicationServerConnectorFactory.(ApplicationServerConnectorFactory.java:74)
> at
> org.apache.nifi.registry.jetty.JettyServer.configureConnectors(JettyServer.java:150)
> at
> org.apache.nifi.registry.jetty.JettyServer.(JettyServer.java:101)
> at org.apache.nifi.registry.NiFiRegistry.(NiFiRegistry.java:114)
> at org.apache.nifi.registry.NiFiRegistry.main(NiFiRegistry.java:168)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: Given
> final block not properly padded. Such issues can arise if a bad key is used
> during decryption.
> at
> java.base/sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.java:446)
> at
> java.base/sun.security.util.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:90)
> at java.base/java.security.KeyStore.getKey(KeyStore.java:1057)
> at
> java.base/sun.security.ssl.SunX509KeyManagerImpl.(SunX509KeyManagerImpl.java:145)
> at
> java.base/sun.security.ssl.KeyManagerFactoryImpl$SunX509.en
[jira] [Assigned] (NIFI-10836) Support Receiving RFC 3195 Syslog Messages
[
https://issues.apache.org/jira/browse/NIFI-10836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough reassigned NIFI-10836:
---
Assignee: Nathan Gough
> Support Receiving RFC 3195 Syslog Messages
> --
>
> Key: NIFI-10836
> URL: https://issues.apache.org/jira/browse/NIFI-10836
> Project: Apache NiFi
> Issue Type: Improvement
> Components: MiNiFi
>Reporter: CHANDAN KUMAR
>Assignee: Nathan Gough
>Priority: Major
>
> [RFC 3195|https://www.rfc-editor.org/rfc/rfc3195] defines a reliable delivery
> format for syslog messages. The {{ListenTCP}} and {{ListenSyslog}} Processors
> do not work with this format because messages span multiple lines and both
> processors expect messages to be terminated by a single newline. A new
> processor could be created to support handling RFC 3195 messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10916) Controller Service allowable values dropdown list should be sorted
[ https://issues.apache.org/jira/browse/NIFI-10916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10916: Fix Version/s: 1.20.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Controller Service allowable values dropdown list should be sorted > -- > > Key: NIFI-10916 > URL: https://issues.apache.org/jira/browse/NIFI-10916 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Minor > Fix For: 1.20.0 > > Attachments: NIFI-10916.png > > Time Spent: 40m > Remaining Estimate: 0h > > When a processor (or controller service) configuration property allows for > the selection of a controller service (via combobox), the available values > should be sorted, to facilitate selection of the intended controller service. > See attachment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10899) Apply SameSite Attribute to Cookies
[
https://issues.apache.org/jira/browse/NIFI-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10899:
Fix Version/s: 1.20.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Apply SameSite Attribute to Cookies
> ---
>
> Key: NIFI-10899
> URL: https://issues.apache.org/jira/browse/NIFI-10899
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Security
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.20.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The standard {{Authorization-Bearer}} cookie includes the
> [SameSite|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite]
> attribute in the {{Set-Cookie}} response header, but other cookies for CSRF
> mitigation, logout processing, and external authentication service
> integration do not apply the attribute when setting cookies.
> The Java Servlet
> [Cookie|https://docs.oracle.com/javaee/7/api/javax/servlet/http/Cookie.html]
> does not support the {{SameSite}} attribute, but the NiFi
> {{StandardApplicationCookieService}} uses the Spring Response Cookie Builder,
> which supports the attribute and is capable of applying it to {{Set-Cookie}}
> headers. Direct use of the Java Servlet {{Cookie}} should be replaced with
> the implementation approach that supports setting the {{SameSite}} attribute
> to avoid warnings in modern browsers. In absence of the {{SameSite}}
> attribute, browsers default to {{{}Lax{}}}, but this can be changed to
> {{Strict}} in most cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10939) When a Inner Versioned Flow's version changes, all changes within that group are shown
[ https://issues.apache.org/jira/browse/NIFI-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642764#comment-17642764 ] Nathan Gough commented on NIFI-10939: - Refreshing canvas or the browser still shows the outer PG as 'modified' after the inner PG is committed. Again, not exactly sure what the desired behavior is but I can only assume we don't want users to have to commit every nested PG if the most inner one is committed? To give a concrete example, if I have an outer PG, inner PG, and inner-inner PG, and commit a change inside the inner-inner PG, I will now see uncommitted changes to inner PG. I commit the changes for the inner PG, and I'll now see changes for outer PG that I would have to commit. If this is an unfortunate fact of how nested versions works right now, I guess that's fine, but perhaps this is unexpected. > When a Inner Versioned Flow's version changes, all changes within that group > are shown > -- > > Key: NIFI-10939 > URL: https://issues.apache.org/jira/browse/NIFI-10939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.20.0, 1.19.1 > > > I created a dataflow and placed it under version control. > I then placed the outer group under version control. > I proceeded to update the flow in the 'inner' group and save those changes. > Now, when I view changes to the outer group, it shows that the version does > not match, but it also shows every difference between my flow and the > previous version of the inner flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10939) When a Inner Versioned Flow's version changes, all changes within that group are shown
[ https://issues.apache.org/jira/browse/NIFI-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642756#comment-17642756 ] Nathan Gough commented on NIFI-10939: - On verifying this fix, I now see that an uncommitted change made to the inner will not show uncommitted changes for the outer. However, once the inner changes are committed, I see the outer PG will then change to uncommitted changes. Is this the desired behavior? > When a Inner Versioned Flow's version changes, all changes within that group > are shown > -- > > Key: NIFI-10939 > URL: https://issues.apache.org/jira/browse/NIFI-10939 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.20.0, 1.19.1 > > > I created a dataflow and placed it under version control. > I then placed the outer group under version control. > I proceeded to update the flow in the 'inner' group and save those changes. > Now, when I view changes to the outer group, it shows that the version does > not match, but it also shows every difference between my flow and the > previous version of the inner flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10938) If a Ghost Registry Client is created, the message indicates that the Reporting Task type is invalid
[ https://issues.apache.org/jira/browse/NIFI-10938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-10938. - Fix Version/s: 1.20.0 1.19.1 Resolution: Fixed > If a Ghost Registry Client is created, the message indicates that the > Reporting Task type is invalid > > > Key: NIFI-10938 > URL: https://issues.apache.org/jira/browse/NIFI-10938 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Trivial > Fix For: 1.20.0, 1.19.1 > > > When I removed the NAR for a particular Registry Client and restarted, NiFi > started up properly, created a ghosted component for the client. However, the > error message indicated that the type of the Reporting Task was invalid, > instead of the type of the Registry Client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10937) If Registry Client exists in flow, NiFi will fail to startup from flow.xml.gz
[
https://issues.apache.org/jira/browse/NIFI-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough resolved NIFI-10937.
-
Fix Version/s: 1.20.0
1.19.1
Resolution: Fixed
> If Registry Client exists in flow, NiFi will fail to startup from flow.xml.gz
> -
>
> Key: NIFI-10937
> URL: https://issues.apache.org/jira/browse/NIFI-10937
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.20.0, 1.19.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If there exists a flow and a Registry Client has been added, upon restart
> everything loads properly from the flow.json.gz. But if for any reason we
> attempt to load from flow.xml.gz (because flow.json.gz was removed), NiFi
> will fail to startup with a NullPointerException:
> {code:java}
> 2022-12-02 16:15:35,462 WARN [main] org.apache.nifi.web.server.JettyServer
> Failed to start web server... shutting down.
> java.lang.NullPointerException: null
> at
> java.util.Comparator.lambda$comparing$77a9974f$1(Comparator.java:469)
> at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355)
> at java.util.TimSort.sort(TimSort.java:220)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1464)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.addFlowControllerFingerprint(FingerprintFactory.java:200)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.createFingerprint(FingerprintFactory.java:155)
> at
> org.apache.nifi.fingerprint.FingerprintFactory.createFingerprint(FingerprintFactory.java:129)
> at
> org.apache.nifi.controller.inheritance.FlowFingerprintCheck.checkInheritability(FlowFingerprintCheck.java:45)
> at
> org.apache.nifi.controller.XmlFlowSynchronizer.sync(XmlFlowSynchronizer.java:205)
> at
> org.apache.nifi.controller.serialization.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:42)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1525)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:104)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:817)
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:538)
> at
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:67)
> at
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:1073)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:572)
> at
> org.eclipse.jetty.server.handler.ContextHandler.contextInitialized(ContextHandler.java:1002)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:765)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:379)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1449)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1414)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:916)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:288)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
> at
> org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:426)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:
[jira] [Commented] (NIFI-10177) Nifi Registry logout via OIDC
[
https://issues.apache.org/jira/browse/NIFI-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642137#comment-17642137
]
Nathan Gough commented on NIFI-10177:
-
PR #6637 added/corrected the logout functionality for OIDC in NiFi registry for
public OIDC providers. I've created a subsequent PR to fix the original stated
issue of private providers (like Keycloak as reported above).
> Nifi Registry logout via OIDC
> -
>
> Key: NIFI-10177
> URL: https://issues.apache.org/jira/browse/NIFI-10177
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
>Affects Versions: 1.16.3
>Reporter: kim myungwon
>Assignee: Emilio Setiadarma
>Priority: Major
> Fix For: 1.20.0, 1.19.1
>
> Attachments: image-2022-06-29-12-41-52-164.png,
> image-2022-06-29-12-42-48-430.png, image-2022-06-29-12-43-25-441.png,
> image-2022-06-29-12-43-48-726.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> I am trying to login and logout via {*}OIDC{*}.
> Login via OIDC is well. but *{color:#de350b}logout via OIDC is not
> working.{color}*
>
> {color:#172b4d}When I logout, NiFi Registry shows "Please contact your System
> Administrator." error message.{color}
> !image-2022-06-29-12-41-52-164.png|width=1134,height=213!
>
> nifi-registry-app.log (debug level)
> {code:java}
> 022-06-29 13:32:35,691 DEBUG [NiFi Registry Web Server-15]
> o.a.nifi.registry.db.DatabaseKeyService Deleting key with identity='myungwon'.
> 2022-06-29 13:32:35,697 INFO [NiFi Registry Web Server-15]
> o.a.n.r.w.s.a.jwt.JwtService Deleted token from database.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.IdentityFilter Attempting to extract user credentials using
> X509IdentityProvider
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.x.X509CertificateExtractor No client certificate found in
> request.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.IdentityFilter Attempting to extract user credentials using
> JwtIdentityProvider
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.s.a.BearerAuthIdentityProvider HTTP Bearer Auth credentials not
> present. Not attempting to extract credentials for authentication.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.AnonymousIdentityFilter Set SecurityContextHolder to anonymous
> SecurityContext
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.ResourceAuthorizationFilter Request filter authorization check
> is not required for this HTTP Method on this resource. Allowing request to
> proceed. An additional authorization check might be performed downstream of
> this filter.
> 2022-06-29 13:32:35,799 INFO [NiFi Registry Web Server-21]
> o.a.n.r.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException:
> Kerberos service ticket login not supported by this NiFi Registry. Returning
> Conflict response.
> 2022-06-29 13:32:35,799 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.m.IllegalStateExceptionMapper
> java.lang.IllegalStateException: Kerberos service ticket login not supported
> by this NiFi Registry
> at
> org.apache.nifi.registry.web.api.AccessResource.createAccessTokenUsingKerberosTicket(AccessResource.java:348)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:475)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:397)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:81)
> at
> org.glass
[jira] [Comment Edited] (NIFI-10177) Nifi Registry logout via OIDC
[
https://issues.apache.org/jira/browse/NIFI-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642137#comment-17642137
]
Nathan Gough edited comment on NIFI-10177 at 12/1/22 7:44 PM:
--
PR #6637 added/corrected the logout functionality for OIDC in NiFi registry for
public OIDC providers. I've created a subsequent Jira NIFI-10924 to fix the
original stated issue of private providers (like Keycloak as reported above).
was (Author: thenatog):
PR #6637 added/corrected the logout functionality for OIDC in NiFi registry for
public OIDC providers. I've created a subsequent PR to fix the original stated
issue of private providers (like Keycloak as reported above).
> Nifi Registry logout via OIDC
> -
>
> Key: NIFI-10177
> URL: https://issues.apache.org/jira/browse/NIFI-10177
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
>Affects Versions: 1.16.3
>Reporter: kim myungwon
>Assignee: Emilio Setiadarma
>Priority: Major
> Fix For: 1.20.0, 1.19.1
>
> Attachments: image-2022-06-29-12-41-52-164.png,
> image-2022-06-29-12-42-48-430.png, image-2022-06-29-12-43-25-441.png,
> image-2022-06-29-12-43-48-726.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> I am trying to login and logout via {*}OIDC{*}.
> Login via OIDC is well. but *{color:#de350b}logout via OIDC is not
> working.{color}*
>
> {color:#172b4d}When I logout, NiFi Registry shows "Please contact your System
> Administrator." error message.{color}
> !image-2022-06-29-12-41-52-164.png|width=1134,height=213!
>
> nifi-registry-app.log (debug level)
> {code:java}
> 022-06-29 13:32:35,691 DEBUG [NiFi Registry Web Server-15]
> o.a.nifi.registry.db.DatabaseKeyService Deleting key with identity='myungwon'.
> 2022-06-29 13:32:35,697 INFO [NiFi Registry Web Server-15]
> o.a.n.r.w.s.a.jwt.JwtService Deleted token from database.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.IdentityFilter Attempting to extract user credentials using
> X509IdentityProvider
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.x.X509CertificateExtractor No client certificate found in
> request.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.IdentityFilter Attempting to extract user credentials using
> JwtIdentityProvider
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.s.a.BearerAuthIdentityProvider HTTP Bearer Auth credentials not
> present. Not attempting to extract credentials for authentication.
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.AnonymousIdentityFilter Set SecurityContextHolder to anonymous
> SecurityContext
> 2022-06-29 13:32:35,797 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.s.a.ResourceAuthorizationFilter Request filter authorization check
> is not required for this HTTP Method on this resource. Allowing request to
> proceed. An additional authorization check might be performed downstream of
> this filter.
> 2022-06-29 13:32:35,799 INFO [NiFi Registry Web Server-21]
> o.a.n.r.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException:
> Kerberos service ticket login not supported by this NiFi Registry. Returning
> Conflict response.
> 2022-06-29 13:32:35,799 DEBUG [NiFi Registry Web Server-21]
> o.a.n.r.w.m.IllegalStateExceptionMapper
> java.lang.IllegalStateException: Kerberos service ticket login not supported
> by this NiFi Registry
> at
> org.apache.nifi.registry.web.api.AccessResource.createAccessTokenUsingKerberosTicket(AccessResource.java:348)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
> at
> org.glassfish.jersey.server.
[jira] [Created] (NIFI-10924) Include NiFi truststore/SSLContext to Registry's outgoing OIDC HTTP requests
Nathan Gough created NIFI-10924: --- Summary: Include NiFi truststore/SSLContext to Registry's outgoing OIDC HTTP requests Key: NIFI-10924 URL: https://issues.apache.org/jira/browse/NIFI-10924 Project: Apache NiFi Issue Type: Sub-task Reporter: Nathan Gough Assignee: Emilio Setiadarma As per the parent Jira [NIFI-10177], we need to include the NiFi SSLContext in outgoing requests to allow privately signed certificates on the OIDC provider side. The previous PR (#6637) enabled OIDC logout with public providers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10903) Fix NiFi Registry assembly profiles
Nathan Gough created NIFI-10903: --- Summary: Fix NiFi Registry assembly profiles Key: NIFI-10903 URL: https://issues.apache.org/jira/browse/NIFI-10903 Project: Apache NiFi Issue Type: Improvement Reporter: Nathan Gough Assignee: Nathan Gough NiFi Registry no longer builds the directory by default when compiling the NiFi project, and only builds a zip of the compiled assembly. Can we update this to build both zip and dir by default? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10785) Allow publishing AMQP message with null header value
[ https://issues.apache.org/jira/browse/NIFI-10785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10785: Fix Version/s: 1.20.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Allow publishing AMQP message with null header value > > > Key: NIFI-10785 > URL: https://issues.apache.org/jira/browse/NIFI-10785 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Nandor Soma Abonyi >Assignee: Nandor Soma Abonyi >Priority: Minor > Labels: amqp > Fix For: 1.20.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Since after NIFI-10317 ConsumeAMQP is able to handle null header value it > makes sense to support it in PublishAMQP. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10755) Streamline SSLContext Creation using nifi-security-ssl
[
https://issues.apache.org/jira/browse/NIFI-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10755:
Fix Version/s: 1.19.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Streamline SSLContext Creation using nifi-security-ssl
> --
>
> Key: NIFI-10755
> URL: https://issues.apache.org/jira/browse/NIFI-10755
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Labels: security
> Fix For: 1.19.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Multiple components have similar code for creating instances of
> {{SSLContext}} from configuration properties. The recent introduction of the
> {{nifi-security-ssl}} module in {{nifi-commons}} provides a reusable builder
> class with no additional dependencies. Manual creation of {{SSLContext}}
> should be refactored where possible to use the shared library.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10851) On update to controller service reference in processor configuration, ensure removal of old reference
[
https://issues.apache.org/jira/browse/NIFI-10851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10851:
Description:
https://lists.apache.org/thread/jjjopqndrp9y6dzdnjxsdfhw2ofjh469
{quote}I'm using NiFi 1.18.0, and I use the controller services configure,
enable or disable screen, to determine what processors is using it. That way I
can determine if I can delete the controller service or not. Or, if I have to
migrate from 1 controller service to a controller service in a processor group.
(For instance, my flow gets too big, so I move the processors to a group, but
the controller services stay at the root level.) (That way I can know for sure
a controller service can get deleted because nothing is using it, rather than
deleting the controller service and having to find all processors after the
fact that are now invalid because of that.)
To test this, I was able to do the following. Create a processor group, add
ConvertRecord in the group, and choose a standard AvroReader as the service at
the root level. Name all of them for uniqueness. Copy the processor group, go
into the ConvertRecord and choose a new processor group level AvroReader, and
name these items uniquely as well. Go back to the root level and look at the
root AvroReader, and it was showing both ConvertRecords, even the one in the
copied group that has a new AvroReader in it.
I just tried that test in a 1.9.0 NiFi instance, and it didn't have the same
problem.{quote}
was:https://lists.apache.org/thread/jjjopqndrp9y6dzdnjxsdfhw2ofjh469
> On update to controller service reference in processor configuration, ensure
> removal of old reference
> -
>
> Key: NIFI-10851
> URL: https://issues.apache.org/jira/browse/NIFI-10851
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Paul Grey
>Assignee: Paul Grey
>Priority: Minor
> Fix For: 1.19.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://lists.apache.org/thread/jjjopqndrp9y6dzdnjxsdfhw2ofjh469
> {quote}I'm using NiFi 1.18.0, and I use the controller services configure,
> enable or disable screen, to determine what processors is using it. That way
> I can determine if I can delete the controller service or not. Or, if I have
> to migrate from 1 controller service to a controller service in a processor
> group. (For instance, my flow gets too big, so I move the processors to a
> group, but the controller services stay at the root level.) (That way I can
> know for sure a controller service can get deleted because nothing is using
> it, rather than deleting the controller service and having to find all
> processors after the fact that are now invalid because of that.)
> To test this, I was able to do the following. Create a processor group, add
> ConvertRecord in the group, and choose a standard AvroReader as the service
> at the root level. Name all of them for uniqueness. Copy the processor group,
> go into the ConvertRecord and choose a new processor group level AvroReader,
> and name these items uniquely as well. Go back to the root level and look at
> the root AvroReader, and it was showing both ConvertRecords, even the one in
> the copied group that has a new AvroReader in it.
> I just tried that test in a 1.9.0 NiFi instance, and it didn't have the same
> problem.{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10816) Nested versioning not working after upgrading to 1.18.0
[
https://issues.apache.org/jira/browse/NIFI-10816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough resolved NIFI-10816.
-
Assignee: Nathan Gough
Resolution: Fixed
I'm fairly confident after testing that this issue has been resolved in
[NIFI-10787].
> Nested versioning not working after upgrading to 1.18.0
> ---
>
> Key: NIFI-10816
> URL: https://issues.apache.org/jira/browse/NIFI-10816
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Bryan Bende
>Assignee: Nathan Gough
>Priority: Major
>
> Reported in Apache NiFi Slack...
>
> We have just upgraded to NiFi 1.18 and we have an issue with Nested Process
> Groups. We are using NiFi registry for versioning.Prior to the upgrade 1.17.0
> has produced the following snapshots when versioning PGs. Below is the part
> that references the nested PG.
> json
> "versionedFlowCoordinates" : \{
> "bucketId" : "c0ad0d17-9b50-4dff-8fca-fd6504cfee50",
> "flowId" : "8acc6ce2-e425-4b91-a089-b7efc6afed8a",
> "registryUrl" : "https:/my-domain:18443",
> "version" : 3
> }
> After the update we concluded that the {{registryUrl}} field is not part of
> the PG in the snapshot.
> json
> "versionedFlowCoordinates" : \{
> "bucketId" : "c0ad0d17-9b50-4dff-8fca-fd6504cfee50",
> "flowId" : "8acc6ce2-e425-4b91-a089-b7efc6afed8a",
> "version" : 4
> }
> Hence when importing to NiFi we get the following
> exception:{{{}org.apache.nifi.registry.flow.FlowRegistryException: No
> applicable registry found for storage location null{}}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10833) Fix grammar error in ListenHTTP log msg
[
https://issues.apache.org/jira/browse/NIFI-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough resolved NIFI-10833.
-
Fix Version/s: 1.19.0
Resolution: Fixed
> Fix grammar error in ListenHTTP log msg
> ---
>
> Key: NIFI-10833
> URL: https://issues.apache.org/jira/browse/NIFI-10833
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Arpad Boda
>Assignee: Arpad Boda
>Priority: Major
> Fix For: 1.19.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> _getLogger().warn("failed to receive{+}*d*{+} acknowledgment for HOLD_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10787) Cannot commit flows to nifi registry after updating our nifi release to 1.18.0
[
https://issues.apache.org/jira/browse/NIFI-10787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough resolved NIFI-10787.
-
Fix Version/s: 1.19.0
Resolution: Fixed
> Cannot commit flows to nifi registry after updating our nifi release to 1.18.0
> --
>
> Key: NIFI-10787
> URL: https://issues.apache.org/jira/browse/NIFI-10787
> Project: Apache NiFi
> Issue Type: Bug
> Components: Flow Versioning
>Affects Versions: 1.18.0
>Reporter: Ahsan
>Assignee: Seda Dogan
>Priority: Blocker
> Fix For: 1.19.0
>
> Attachments: index.png, stacktrace_nifi.txt,
> stacktrace_nifi_registry.txt
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Hi,
>
> So we recently updated to Nifi 1.18.0 and registry to 1.18.0.
> Some portions of our flows were for no reason not "Commitable" any more.
> Attached are the stacktraces from nifi and nifi-registry, when we click the
> commit local changes button in nifi.
>
> Thinking this is a problem on our end, we debugged the issue and found out
> the following:
> The method in
> "src/main/java/org/apache/nifi/registry/flow/mapping/NiFiRegistryFlowMapper.java"
> below is where things trip and we get a NPE.
> {code:java}
> private String getRegistryUrl(final FlowRegistryClientNode registry) {
> return
> registry.getComponentType().equals("org.apache.nifi.registry.flow.NifiRegistryFlowRegistryClient")
> ? registry.getRawPropertyValue(registry.getPropertyDescriptor("URL")) : "";
> } {code}
> If you note the call "registry.getPropertyDescriptor("URL")" with the
> hard-coded string "URL", this is failing although the property is there BUT
> with the name in small case "url".
> I say this is because if we look at the class
> {color:#6a8759}"NifiRegistryFlowRegistryClient", {color}the url property is
> described as following:
> {code:java}
> public final static PropertyDescriptor PROPERTY_URL = new
> PropertyDescriptor.Builder()
> .name("url")
> .displayName("URL")
> .description("URL of the NiFi Registry")
> .addValidator(StandardValidators.URL_VALIDATOR)
> .required(true)
> .build();{code}
> And if you note the property name is described with small case "url". Hence
> PropertyDescriptor which bases its hash on the "name" property fails when we
> search with uppercase "URL".
> {code:java}
> // hash def of
> nifi-api/src/main/java/org/apache/nifi/components/PropertyDescriptor.java
> @Override
> public int hashCode() {
> return 287 + this.name.hashCode() * 47;
> } {code}
> Hope I have helped here. Can someone fix this issue. We cannot commit in our
> registry currently because of the NPE.
>
> Just in case the debug stacktrace is important showing the src
> PropertyDescription being used to search for in the map, I attach it here:
>
> !index.png!
>
> Regards
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10243) ControlRate throttle on both flowfile and byte count
[ https://issues.apache.org/jira/browse/NIFI-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10243: Fix Version/s: 1.19.0 Resolution: Fixed Status: Resolved (was: Patch Available) > ControlRate throttle on both flowfile and byte count > > > Key: NIFI-10243 > URL: https://issues.apache.org/jira/browse/NIFI-10243 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.16.3 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Fix For: 1.19.0 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > Request the ability for a ControlRate component to throttle based upon > multiple thresholds. Currently, you can only set the "Rate Control Criteria" > of "data rate", or "flowfile count". Allowing you to set either a "byte" > threshold OR "flowfile count" threshold. > > Requesting the ability to optionally include values for both... so > essentially a throttle would kick in whenever either threshold is met. This > is particularly useful with varying datasets that contain many small objects > within potentially small sized files that might otherwise fly underneath the > threshold that was meant to limit overall file counts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10705) includePrimaryKeys has wrong value when statementType set to "User statement.type Attribute""
[
https://issues.apache.org/jira/browse/NIFI-10705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17632071#comment-17632071
]
Nathan Gough commented on NIFI-10705:
-
I can see that 'includePrimaryKeys' will be false when it should be true if
'User statement.type Attribute' is used and 'UPDATE' is the given attribute
value. I will submit a PR with a unit test to fix the issue.
> includePrimaryKeys has wrong value when statementType set to "User
> statement.type Attribute""
> -
>
> Key: NIFI-10705
> URL: https://issues.apache.org/jira/browse/NIFI-10705
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.18.0
>Reporter: su heng
>Assignee: Nathan Gough
>Priority: Major
> Attachments: ConvertJSONToSQL.patch
>
>
> {code:java}
> final boolean includePrimaryKeys = UPDATE_TYPE.equals(statementType) &&
> updateKeys == null; {code}
> above code should do after evaluate statementType.
> {code:java}
> if (USE_ATTR_TYPE.equals(statementType)) {
> statementType = flowFile.getAttribute(STATEMENT_TYPE_ATTRIBUTE);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (NIFI-10705) includePrimaryKeys has wrong value when statementType set to "User statement.type Attribute""
[
https://issues.apache.org/jira/browse/NIFI-10705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough reassigned NIFI-10705:
---
Assignee: Nathan Gough
> includePrimaryKeys has wrong value when statementType set to "User
> statement.type Attribute""
> -
>
> Key: NIFI-10705
> URL: https://issues.apache.org/jira/browse/NIFI-10705
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.18.0
>Reporter: su heng
>Assignee: Nathan Gough
>Priority: Major
> Attachments: ConvertJSONToSQL.patch
>
>
> {code:java}
> final boolean includePrimaryKeys = UPDATE_TYPE.equals(statementType) &&
> updateKeys == null; {code}
> above code should do after evaluate statementType.
> {code:java}
> if (USE_ATTR_TYPE.equals(statementType)) {
> statementType = flowFile.getAttribute(STATEMENT_TYPE_ATTRIBUTE);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10798) Add Deprecation Logging for Java 8 on Startup
[ https://issues.apache.org/jira/browse/NIFI-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10798: Fix Version/s: 1.19.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Add Deprecation Logging for Java 8 on Startup > - > > Key: NIFI-10798 > URL: https://issues.apache.org/jira/browse/NIFI-10798 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core Framework, MiNiFi, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 1.19.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Warning logs should be added when starting Apache NiFi applications to > indicate that support for Java 8 is deprecated and that Java 11 is the > minimum recommended version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10780) Avoid Dropping Events in Listen Processors for Full Queues
[
https://issues.apache.org/jira/browse/NIFI-10780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10780:
Fix Version/s: 1.19.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Avoid Dropping Events in Listen Processors for Full Queues
> --
>
> Key: NIFI-10780
> URL: https://issues.apache.org/jira/browse/NIFI-10780
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.19.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Multiple listening Processors, including {{ListenSyslog}} and
> {{{}ListenTCP{}}}, depend on the {{nifi-event-transport}} module and the
> {{NettyEventServer}} to receiving incoming messages. These components use the
> {{ByteArrayMessageChannelHandler}} to add parsed messages to a configured
> queue for subsequent processing when the framework triggers the Processor.
> {{ListenSyslog}} and {{ListenTCP}} use a {{LinkedBlockingQueue}} with a
> configurable maximum size as an internal buffer, and
> {{LinkedBlockingQueue.add()}} throws an {{IllegalStateException}} if the
> caller attempts to add an element that exceeds the maximum queue size. As a
> result of this approach, these Processors can drop messages when the maximum
> queue size is too low.
> The supporting {{ByteArrayMessageChannelHandler}} should be improved to call
> a method other than {{LinkedBlockingQueue.add()}} to avoid dropping messages
> while waiting for the Processor to handle queued events.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (NIFI-10685) PutDatabaseRecord Upsert does not quote columns in conflict clause (postgres)
[
https://issues.apache.org/jira/browse/NIFI-10685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough reassigned NIFI-10685:
---
Assignee: Nathan Gough
> PutDatabaseRecord Upsert does not quote columns in conflict clause (postgres)
> -
>
> Key: NIFI-10685
> URL: https://issues.apache.org/jira/browse/NIFI-10685
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.18.0
>Reporter: mgerbig
>Assignee: Nathan Gough
>Priority: Major
> Attachments: putdatabase-test.avro
>
>
> Nifi's PutDatabaseRecord does not quote columns in the conflict clause when
> using PostgreSQLDatabaseAdapter. This prevents the usage of upsert (and
> possibly insert ignore) statements as soon as at least one column of the
> primary key contains at least one uppercase character.
> h2. Root Cause
> Postgres lowercases all unquoted keys, as described in the manual, which
> causes this bug:
> {quote}Quoting an identifier also makes it case-sensitive, whereas unquoted
> names are always folded to lower case. For example, the identifiers
> {{{}FOO{}}}, {{{}foo{}}}, and {{"foo"}} are considered the same by
> PostgreSQL, but {{"Foo"}} and {{"FOO"}} are different from these three and
> each other. (The folding of unquoted names to lower case in PostgreSQL is
> incompatible with the SQL standard, which says that unquoted names should be
> folded to upper case. Thus, {{foo}} should be equivalent to {{"FOO"}} not
> {{"foo"}} according to the standard. If you want to write portable
> applications you are advised to always quote a particular name or never quote
> it.)
> {quote}
> see
> [https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS]
> h2. Reproduce behaviour
> Create a table in your *PostgreSQL* database
> {code:java}
> CREATE TABLE test_table
> (
> "TIME_PERIOD" date NOT NULL,
> "R0102" numeric,
> "R0203" numeric,
> "R0304" numeric,
> "R0405" numeric,
> "R0506" numeric,
> "R0607" numeric,
> "R0708" numeric,
> "R0809" numeric,
> "R0910" numeric,
> modified_at_utc date DEFAULT timezone('UTC'::text, CURRENT_TIMESTAMP(0)),
> CONSTRAINT test_table PRIMARY KEY ("TIME_PERIOD")
> ) {code}
> Use attached avro to write to the table using a PutDatabaseRecord Processor
> configured with UPSERT.
> Nifi will throw following Exception in the Bulletin Board
> {code:java}
> PutDatabaseRecord[id=...] Failed to put Records to database for
> FlowFile[filename=redacted.avro]. Routing to failure.:
> java.sql.BatchUpdateException: Batch entry 0 INSERT INTO
> "public"."test_table"("TIME_PERIOD", "R0102", "R0203", "R0304", "R0405",
> "R0506", "R0607", "R0708", "R0809", "R0910") VALUES ('2022-10-21 +00',
> '2.97'::numeric, '3.2'::numeric, '3.19'::numeric, '3.19'::numeric,
> '3.22'::numeric, '3.33'::numeric, '3.33'::numeric, '3.4'::numeric,
> '3.38'::numeric) ON CONFLICT (TIME_PERIOD) DO UPDATE SET ("TIME_PERIOD",
> "R0102", "R0203", "R0304", "R0405", "R0506", "R0607", "R0708", "R0809",
> "R0910") = (EXCLUDED."TIME_PERIOD", EXCLUDED."R0102", EXCLUDED."R0203",
> EXCLUDED."R0304", EXCLUDED."R0405", EXCLUDED."R0506", EXCLUDED."R0607",
> EXCLUDED."R0708", EXCLUDED."R0809", EXCLUDED."R0910") was aborted: ERROR:
> column "time_period" does not exist
> Position: 347 Call getNextException to see other errors in the batch.
> - Caused by: org.postgresql.util.PSQLException: ERROR: column "time_period"
> does not exist
> Position: 347 {code}
> h3. Generated SQL Statement
> Nifi generates and issues following SQL Statement to the database:
> {code:java}
> INSERT INTO "public"."test_table"("TIME_PERIOD", "R0102", "R0203", "R0304",
> "R0405", "R0506", "R0607", "R0708", "R0809", "R0910") VALUES (?, ?, ?, ?, ?,
> ?, ?, ?, ?, ?) ON CONFLICT (TIME_PERIOD) DO UPDATE SET ("TIME_PERIOD",
> "R0102", "R0203", "R0304", "R0405", "R0506", "R0607", "R0708", "R0809",
> "R0910") = (EXCLUDED."TIME_PERIOD", EXCLUDED."R0102", EXCLUDED."R0203",
> EXCLUDED."R0304", EXCLUDED."R0405", EXCLUDED."R0506", EXCLUDED."R0607",
> EXCLUDED."R0708", EXCLUDED."R0809", EXCLUDED."R0910") {code}
> This statement only works with quoted _TIME_PERIOD_ in the _ON CONFLICT_
> clause due to the behaviour of postgres described in Section _Root Cause_
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10703) Event Driven Thread Count resets on NiFi restart
[ https://issues.apache.org/jira/browse/NIFI-10703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630646#comment-17630646 ] Nathan Gough commented on NIFI-10703: - I was able to confirm this issue, but I'm questioning whether leaving out the event driven thread config from the flow.json was an intentional choice. It's a relatively easy fix of adding a setter and getting to the versioned data flow implementation, but I have a suspicion it was left out for a reason. [~markap14] can you comment on this? I guess we can try to find a way to not have this keep resetting on every restart though. > Event Driven Thread Count resets on NiFi restart > > > Key: NIFI-10703 > URL: https://issues.apache.org/jira/browse/NIFI-10703 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.18.0 >Reporter: Mark Bean >Assignee: Nathan Gough >Priority: Minor > > The controller setting for Maximum Event Driven Thread Count is reset to "1" > after restarting NiFi. This occurs because this property is not written to > the flow.json.gz file; it is only present in the flow.xml.gz. > Therefore, until this issue is reolved and the property added to the JSON, a > work-around is to remove the flow.json.gz before restarting NiFi. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-10703) Event Driven Thread Count resets on NiFi restart
[ https://issues.apache.org/jira/browse/NIFI-10703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough reassigned NIFI-10703: --- Assignee: Nathan Gough > Event Driven Thread Count resets on NiFi restart > > > Key: NIFI-10703 > URL: https://issues.apache.org/jira/browse/NIFI-10703 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.18.0 >Reporter: Mark Bean >Assignee: Nathan Gough >Priority: Minor > > The controller setting for Maximum Event Driven Thread Count is reset to "1" > after restarting NiFi. This occurs because this property is not written to > the flow.json.gz file; it is only present in the flow.xml.gz. > Therefore, until this issue is reolved and the property added to the JSON, a > work-around is to remove the flow.json.gz before restarting NiFi. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10739) ConsumeAMQP fails
[
https://issues.apache.org/jira/browse/NIFI-10739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough resolved NIFI-10739.
-
Resolution: Duplicate
Thank you Fabien for your report and assistance with getting NIFI-10317 closed
> ConsumeAMQP fails
> -
>
> Key: NIFI-10739
> URL: https://issues.apache.org/jira/browse/NIFI-10739
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.16.3, 1.18.0
> Environment: centos 7 - openjdk 1.8 & openjdk 1.11
>Reporter: Fabien Sarcel
>Assignee: Nathan Gough
>Priority: Major
>
> ConsumeAMQP was working fine until 1.15.2 ({_}centos 7 & openjdk 1.8.0{_}),
> but it fails with 1.16.3 and 1.18.0 ({_}I tried openjdk 1.8.0 and 1.11.0{_}).
> I suspect that's related to "Framework Level Retry" introduced with 1.16:
> ~2022-10-31 10:37:05,663 WARN [Timer-Driven Process Thread-8]
> o.a.n.controller.tasks.ConnectableTask Processing halted: uncaught exception
> in Component [ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142]]~
> ~org.apache.nifi.processor.exception.FlowFileHandlingException:
> StandardFlowFileRecord[uuid=25233bf6-17c7-4829-a3bd-72bf10059687,claim=StandardContentClaim
> [resourceClaim=StandardResourceClaim[id=1667211444369-19, container=default,
> section=19], offset=2910879,
> length=654],offset=0,name=25233bf6-17c7-4829-a3bd-72bf10059687,size=654]
> transfer relationship not specified. This FlowFile was created in this
> session and was not transferred to any Relationship via
> ProcessSession.transfer()~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.validateCommitState(StandardProcessSession.java:259)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.checkpoint(StandardProcessSession.java:274)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:556)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.commitAsync(StandardProcessSession.java:510)~
> ~at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28)~
> ~at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1354)~
> ~at
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:246)~
> ~at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:102)~
> ~at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)~
> ~at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)~
> ~at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)~
> ~at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)~
> ~at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)~
> ~at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)~
> ~at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)~
> ~at java.lang.Thread.run(Thread.java:750)~
> ~2022-10-31 10:37:06,827 INFO [Timer-Driven Process Thread-5]
> o.a.nifi.amqp.processors.ConsumeAMQP
> ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142] Successfully connected
> AMQPConsumer to amqp://***{*}@{*} and '***' queue~
> ~2022-10-31 10:37:09,050 INFO [Timer-Driven Process Thread-1]
> o.a.n.p.store.WriteAheadStorePartition Successfully rolled over Event Writer
> for Provenance Event Store
> Partition[directory=/opt/nifi/conf/provenance_repository] due to
> MAX_TIME_REACHED. Event File was 156.19 KB and contained 99 events.~
> ~2022-10-31 10:37:10,687 INFO [Clustering Tasks Thread-2]
> o.a.n.c.c.ClusterProtocolHeartbeater Heartbeat created at 2022-10-31
> 10:37:10,588 and sent to sprint-nifi-3:9876 at 2022-10-31 10:37:10,687;
> determining Cluster Coordinator took 1 millis; DNS lookup for coordinator
> took 0 millis; connecting to coordinator took 1 millis; sending heartbeat
> took 93 millis; receiving first byte from response took 2 millis; receiving
> full response took 3 millis; total time was 99 millis~
> ~2022-10-31 10:37:11,650 INFO [Cleanup Archive for default]
> o.a.n.c.repository.FileSystemRepository Successfully deleted 0 files (0
> bytes) from archive~
> ~2022-10-31 10:37:11,650 INFO [Cleanup Archive for default]
> o.a.n.c.repository.FileSystemRepository Archive cleanup completed for
> container default; will now allow writing to this container. Bytes used =
> 22.25 GB, bytes free = 80.98 GB, capacity = 103.23 GB~
> ~2022-10-31 10:37:11,837 ERROR [Timer-Driven Process Thread-5]
> o.a.nifi.amqp.processors.ConsumeAMQP
> ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142] Processor failure~
> ~java.lang.NullPointerException: null~
--
This mes
[jira] [Updated] (NIFI-10317) NullPointerException if AMQP header value is null
[ https://issues.apache.org/jira/browse/NIFI-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10317: Fix Version/s: 1.19.0 Resolution: Fixed Status: Resolved (was: Patch Available) > NullPointerException if AMQP header value is null > - > > Key: NIFI-10317 > URL: https://issues.apache.org/jira/browse/NIFI-10317 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.16.0 >Reporter: Yury Kosharovskiy >Assignee: Saumya Gurtu >Priority: Critical > Fix For: 1.19.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Unhandled NullPointerException is thrown if AMQP header value is null: > https://github.com/apache/nifi/blob/rel/nifi-1.16.0/nifi-nar-bundles/nifi-amqp-bundle/nifi-amqp-processors/src/main/java/org/apache/nifi/amqp/processors/ConsumeAMQP.java#L237 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10737) ListenBeats Unable to Process Large Batches
[
https://issues.apache.org/jira/browse/NIFI-10737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10737:
Fix Version/s: 1.19.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> ListenBeats Unable to Process Large Batches
> ---
>
> Key: NIFI-10737
> URL: https://issues.apache.org/jira/browse/NIFI-10737
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.16.0, 1.17.0, 1.18.0
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.19.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Refactoring of ListenBeats released in version 1.16.0 introduced processing
> issues when reading batches of messages larger than 2048 bytes.
> The refactored implementation based on Netty introduced a
> {{BeatsFrameDecoder}} extension of the Netty {{{}ByteToMessageDecoder{}}},
> which the Netty framework invokes multiple times with variables contents of
> the input {{{}ByteBuf{}}}. The implementation does not handle scenarios where
> a batch of multiple messages is larger than the buffer size of 2048. As a
> result of this behavior, the Decoder does not construct a complete message.
> Without the complete message, the Processor does not send an acknowledgement
> for the received message, resulting in errors on sending clients, such as the
> following:
> {noformat}
> Failed to publish events caused by: read tcp
> 192.168.1.100:54623->192.168.1.200:: i/o timeout
> {noformat}
> This error occurs on sending client while waiting to receive an
> acknowledgement packet for the messages transmitted.
> As a result of not receiving the acknowledgement, the client attempts to send
> the same messages multiple times, resulting in duplication and failure to
> send additional messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10506) Documentation : NiFi Repository Encryption : Upgrade Considerations has to be added
[ https://issues.apache.org/jira/browse/NIFI-10506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10506: Fix Version/s: 1.19.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Documentation : NiFi Repository Encryption : Upgrade Considerations has to be > added > --- > > Key: NIFI-10506 > URL: https://issues.apache.org/jira/browse/NIFI-10506 > Project: Apache NiFi > Issue Type: Improvement >Reporter: CHANDAN KUMAR >Assignee: David Handermann >Priority: Minor > Fix For: 1.19.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Upgrade Considerations section needs to be added when enabling and disabling > encryption on nifi repositories in Apache NiFi docs at > https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#repository-encryption-properties > > please refer : > [https://exceptionfactory.com/posts/2021/11/10/configuring-apache-nifi-repository-encryption/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10758) Add Reporting Guidelines to Website Security Policy
[
https://issues.apache.org/jira/browse/NIFI-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10758:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add Reporting Guidelines to Website Security Policy
> ---
>
> Key: NIFI-10758
> URL: https://issues.apache.org/jira/browse/NIFI-10758
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Documentation & Website
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The Apache NiFi project occasionally receives security vulnerability reports
> regarding command execution using certain documented Processors. The Security
> Policy on the project website should be updated to indicate that certain
> types of custom command execution is not considered a security vulnerability
> and should not be reported.
> Components such as ExecuteProcess and ExecuteStreamCommand support running
> configurable operating system commands, and other scripted components such as
> ExecuteGroovyScript support running custom code provided as a property. These
> components have an {{execute code}} permission restriction that can be
> configured for multi-tenant deployments. As a framework designed for building
> complex processing pipelines using little to no code, Apache NiFi provides a
> number of security guarantees at the framework level, but does not restrict
> an authenticated and authorized user from configuring and running custom
> commands.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10739) ConsumeAMQP fails
[
https://issues.apache.org/jira/browse/NIFI-10739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17627834#comment-17627834
]
Nathan Gough commented on NIFI-10739:
-
Thank you, Fabien! I'll review the other issue and see if we can merge the fix
provided.
> ConsumeAMQP fails
> -
>
> Key: NIFI-10739
> URL: https://issues.apache.org/jira/browse/NIFI-10739
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.16.3, 1.18.0
> Environment: centos 7 - openjdk 1.8 & openjdk 1.11
>Reporter: Fabien Sarcel
>Assignee: Nathan Gough
>Priority: Major
>
> ConsumeAMQP was working fine until 1.15.2 ({_}centos 7 & openjdk 1.8.0{_}),
> but it fails with 1.16.3 and 1.18.0 ({_}I tried openjdk 1.8.0 and 1.11.0{_}).
> I suspect that's related to "Framework Level Retry" introduced with 1.16:
> ~2022-10-31 10:37:05,663 WARN [Timer-Driven Process Thread-8]
> o.a.n.controller.tasks.ConnectableTask Processing halted: uncaught exception
> in Component [ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142]]~
> ~org.apache.nifi.processor.exception.FlowFileHandlingException:
> StandardFlowFileRecord[uuid=25233bf6-17c7-4829-a3bd-72bf10059687,claim=StandardContentClaim
> [resourceClaim=StandardResourceClaim[id=1667211444369-19, container=default,
> section=19], offset=2910879,
> length=654],offset=0,name=25233bf6-17c7-4829-a3bd-72bf10059687,size=654]
> transfer relationship not specified. This FlowFile was created in this
> session and was not transferred to any Relationship via
> ProcessSession.transfer()~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.validateCommitState(StandardProcessSession.java:259)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.checkpoint(StandardProcessSession.java:274)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:556)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.commitAsync(StandardProcessSession.java:510)~
> ~at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28)~
> ~at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1354)~
> ~at
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:246)~
> ~at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:102)~
> ~at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)~
> ~at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)~
> ~at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)~
> ~at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)~
> ~at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)~
> ~at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)~
> ~at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)~
> ~at java.lang.Thread.run(Thread.java:750)~
> ~2022-10-31 10:37:06,827 INFO [Timer-Driven Process Thread-5]
> o.a.nifi.amqp.processors.ConsumeAMQP
> ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142] Successfully connected
> AMQPConsumer to amqp://***{*}@{*} and '***' queue~
> ~2022-10-31 10:37:09,050 INFO [Timer-Driven Process Thread-1]
> o.a.n.p.store.WriteAheadStorePartition Successfully rolled over Event Writer
> for Provenance Event Store
> Partition[directory=/opt/nifi/conf/provenance_repository] due to
> MAX_TIME_REACHED. Event File was 156.19 KB and contained 99 events.~
> ~2022-10-31 10:37:10,687 INFO [Clustering Tasks Thread-2]
> o.a.n.c.c.ClusterProtocolHeartbeater Heartbeat created at 2022-10-31
> 10:37:10,588 and sent to sprint-nifi-3:9876 at 2022-10-31 10:37:10,687;
> determining Cluster Coordinator took 1 millis; DNS lookup for coordinator
> took 0 millis; connecting to coordinator took 1 millis; sending heartbeat
> took 93 millis; receiving first byte from response took 2 millis; receiving
> full response took 3 millis; total time was 99 millis~
> ~2022-10-31 10:37:11,650 INFO [Cleanup Archive for default]
> o.a.n.c.repository.FileSystemRepository Successfully deleted 0 files (0
> bytes) from archive~
> ~2022-10-31 10:37:11,650 INFO [Cleanup Archive for default]
> o.a.n.c.repository.FileSystemRepository Archive cleanup completed for
> container default; will now allow writing to this container. Bytes used =
> 22.25 GB, bytes free = 80.98 GB, capacity = 103.23 GB~
> ~2022-10-31 10:37:11,837 ERROR [Timer-Driven Process Thread-5]
> o.a.nifi.amqp.processors.ConsumeAMQP
> ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142] Processor failure~
> ~java.lang.Nu
[jira] [Commented] (NIFI-10739) ConsumeAMQP fails
[
https://issues.apache.org/jira/browse/NIFI-10739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17627364#comment-17627364
]
Nathan Gough commented on NIFI-10739:
-
Hi Fabien, is this an intermittent issue or is no data coming through
ConsumeAMQP at all? Looking to see if I can reproduce the issue you're seeing.
> ConsumeAMQP fails
> -
>
> Key: NIFI-10739
> URL: https://issues.apache.org/jira/browse/NIFI-10739
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.16.3, 1.18.0
> Environment: centos 7 - openjdk 1.8 & openjdk 1.11
>Reporter: Fabien Sarcel
>Assignee: Nathan Gough
>Priority: Major
>
> ConsumeAMQP was working fine until 1.15.2 ({_}centos 7 & openjdk 1.8.0{_}),
> but it fails with 1.16.3 and 1.18.0 ({_}I tried openjdk 1.8.0 and 1.11.0{_}).
> I suspect that's related to "Framework Level Retry" introduced with 1.16:
> ~2022-10-31 10:37:05,663 WARN [Timer-Driven Process Thread-8]
> o.a.n.controller.tasks.ConnectableTask Processing halted: uncaught exception
> in Component [ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142]]~
> ~org.apache.nifi.processor.exception.FlowFileHandlingException:
> StandardFlowFileRecord[uuid=25233bf6-17c7-4829-a3bd-72bf10059687,claim=StandardContentClaim
> [resourceClaim=StandardResourceClaim[id=1667211444369-19, container=default,
> section=19], offset=2910879,
> length=654],offset=0,name=25233bf6-17c7-4829-a3bd-72bf10059687,size=654]
> transfer relationship not specified. This FlowFile was created in this
> session and was not transferred to any Relationship via
> ProcessSession.transfer()~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.validateCommitState(StandardProcessSession.java:259)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.checkpoint(StandardProcessSession.java:274)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:556)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.commitAsync(StandardProcessSession.java:510)~
> ~at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28)~
> ~at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1354)~
> ~at
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:246)~
> ~at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:102)~
> ~at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)~
> ~at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)~
> ~at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)~
> ~at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)~
> ~at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)~
> ~at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)~
> ~at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)~
> ~at java.lang.Thread.run(Thread.java:750)~
> ~2022-10-31 10:37:06,827 INFO [Timer-Driven Process Thread-5]
> o.a.nifi.amqp.processors.ConsumeAMQP
> ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142] Successfully connected
> AMQPConsumer to amqp://***{*}@{*} and '***' queue~
> ~2022-10-31 10:37:09,050 INFO [Timer-Driven Process Thread-1]
> o.a.n.p.store.WriteAheadStorePartition Successfully rolled over Event Writer
> for Provenance Event Store
> Partition[directory=/opt/nifi/conf/provenance_repository] due to
> MAX_TIME_REACHED. Event File was 156.19 KB and contained 99 events.~
> ~2022-10-31 10:37:10,687 INFO [Clustering Tasks Thread-2]
> o.a.n.c.c.ClusterProtocolHeartbeater Heartbeat created at 2022-10-31
> 10:37:10,588 and sent to sprint-nifi-3:9876 at 2022-10-31 10:37:10,687;
> determining Cluster Coordinator took 1 millis; DNS lookup for coordinator
> took 0 millis; connecting to coordinator took 1 millis; sending heartbeat
> took 93 millis; receiving first byte from response took 2 millis; receiving
> full response took 3 millis; total time was 99 millis~
> ~2022-10-31 10:37:11,650 INFO [Cleanup Archive for default]
> o.a.n.c.repository.FileSystemRepository Successfully deleted 0 files (0
> bytes) from archive~
> ~2022-10-31 10:37:11,650 INFO [Cleanup Archive for default]
> o.a.n.c.repository.FileSystemRepository Archive cleanup completed for
> container default; will now allow writing to this container. Bytes used =
> 22.25 GB, bytes free = 80.98 GB, capacity = 103.23 GB~
> ~2022-10-31 10:37:11,837 ERROR [Timer-Driven Process Thread-5]
> o.a.nifi.amqp.processors.ConsumeAMQP
> ConsumeAMQP[id=a64f32ba-04e
[jira] [Assigned] (NIFI-10739) ConsumeAMQP fails
[
https://issues.apache.org/jira/browse/NIFI-10739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough reassigned NIFI-10739:
---
Assignee: Nathan Gough
> ConsumeAMQP fails
> -
>
> Key: NIFI-10739
> URL: https://issues.apache.org/jira/browse/NIFI-10739
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.16.3, 1.18.0
> Environment: centos 7 - openjdk 1.8 & openjdk 1.11
>Reporter: Fabien Sarcel
>Assignee: Nathan Gough
>Priority: Major
>
> ConsumeAMQP was working fine until 1.15.2 ({_}centos 7 & openjdk 1.8.0{_}),
> but it fails with 1.16.3 and 1.18.0 ({_}I tried openjdk 1.8.0 and 1.11.0{_}).
> I suspect that's related to "Framework Level Retry" introduced with 1.16:
> ~2022-10-31 10:37:05,663 WARN [Timer-Driven Process Thread-8]
> o.a.n.controller.tasks.ConnectableTask Processing halted: uncaught exception
> in Component [ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142]]~
> ~org.apache.nifi.processor.exception.FlowFileHandlingException:
> StandardFlowFileRecord[uuid=25233bf6-17c7-4829-a3bd-72bf10059687,claim=StandardContentClaim
> [resourceClaim=StandardResourceClaim[id=1667211444369-19, container=default,
> section=19], offset=2910879,
> length=654],offset=0,name=25233bf6-17c7-4829-a3bd-72bf10059687,size=654]
> transfer relationship not specified. This FlowFile was created in this
> session and was not transferred to any Relationship via
> ProcessSession.transfer()~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.validateCommitState(StandardProcessSession.java:259)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.checkpoint(StandardProcessSession.java:274)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:556)~
> ~at
> org.apache.nifi.controller.repository.StandardProcessSession.commitAsync(StandardProcessSession.java:510)~
> ~at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28)~
> ~at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1354)~
> ~at
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:246)~
> ~at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:102)~
> ~at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)~
> ~at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)~
> ~at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)~
> ~at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)~
> ~at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)~
> ~at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)~
> ~at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)~
> ~at java.lang.Thread.run(Thread.java:750)~
> ~2022-10-31 10:37:06,827 INFO [Timer-Driven Process Thread-5]
> o.a.nifi.amqp.processors.ConsumeAMQP
> ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142] Successfully connected
> AMQPConsumer to amqp://***{*}@{*} and '***' queue~
> ~2022-10-31 10:37:09,050 INFO [Timer-Driven Process Thread-1]
> o.a.n.p.store.WriteAheadStorePartition Successfully rolled over Event Writer
> for Provenance Event Store
> Partition[directory=/opt/nifi/conf/provenance_repository] due to
> MAX_TIME_REACHED. Event File was 156.19 KB and contained 99 events.~
> ~2022-10-31 10:37:10,687 INFO [Clustering Tasks Thread-2]
> o.a.n.c.c.ClusterProtocolHeartbeater Heartbeat created at 2022-10-31
> 10:37:10,588 and sent to sprint-nifi-3:9876 at 2022-10-31 10:37:10,687;
> determining Cluster Coordinator took 1 millis; DNS lookup for coordinator
> took 0 millis; connecting to coordinator took 1 millis; sending heartbeat
> took 93 millis; receiving first byte from response took 2 millis; receiving
> full response took 3 millis; total time was 99 millis~
> ~2022-10-31 10:37:11,650 INFO [Cleanup Archive for default]
> o.a.n.c.repository.FileSystemRepository Successfully deleted 0 files (0
> bytes) from archive~
> ~2022-10-31 10:37:11,650 INFO [Cleanup Archive for default]
> o.a.n.c.repository.FileSystemRepository Archive cleanup completed for
> container default; will now allow writing to this container. Bytes used =
> 22.25 GB, bytes free = 80.98 GB, capacity = 103.23 GB~
> ~2022-10-31 10:37:11,837 ERROR [Timer-Driven Process Thread-5]
> o.a.nifi.amqp.processors.ConsumeAMQP
> ConsumeAMQP[id=a64f32ba-04e6-19d9-8318-52f12cc6f142] Processor failure~
> ~java.lang.NullPointerException: null~
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10740) Upgrade Spring Security to 5.7.5
[ https://issues.apache.org/jira/browse/NIFI-10740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10740: Fix Version/s: 1.19.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Spring Security to 5.7.5 > > > Key: NIFI-10740 > URL: https://issues.apache.org/jira/browse/NIFI-10740 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.19.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Spring Security > [5.7.5|https://github.com/spring-projects/spring-security/releases/tag/5.7.5] > incorporates several bug fixes to request filtering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10738) Improve V3SNMPFactoryTest intermittent failures
Nathan Gough created NIFI-10738: --- Summary: Improve V3SNMPFactoryTest intermittent failures Key: NIFI-10738 URL: https://issues.apache.org/jira/browse/NIFI-10738 Project: Apache NiFi Issue Type: Improvement Affects Versions: 1.18.0 Reporter: Nathan Gough Assignee: Nathan Gough The V3SNMPFactoryTest fails intermittently due to a failure to bind to interface exception. There is likely a race condition occurring between when we try to claim an available port to use in the test and when the server attempts to bind to that address. Currently I can't think of an atomic way to reserve a port and provide it to the server without that server library supporting such a feature, so instead we may have to create a testing method which provides multiple binding attempts by catching a bind exception and retrying some number of times. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10723) Add extra message for PostHTTP when experiencing ClientProtocolException
[ https://issues.apache.org/jira/browse/NIFI-10723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-10723. - Resolution: Won't Fix Closing this due to the changes being for a soon to be deprecated processor > Add extra message for PostHTTP when experiencing ClientProtocolException > > > Key: NIFI-10723 > URL: https://issues.apache.org/jira/browse/NIFI-10723 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > When a PostHTTP processor without SSLContext posts to a remote host running > TLS, PostHTTP has a non-specific message that does not necessarily indicate > the issue. Would be useful to see the error is probably related to HTTPS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10723) Add extra message for PostHTTP when experiencing ClientProtocolException
Nathan Gough created NIFI-10723: --- Summary: Add extra message for PostHTTP when experiencing ClientProtocolException Key: NIFI-10723 URL: https://issues.apache.org/jira/browse/NIFI-10723 Project: Apache NiFi Issue Type: Improvement Reporter: Nathan Gough Assignee: Nathan Gough When a PostHTTP processor without SSLContext posts to a remote host running TLS, PostHTTP has a non-specific message that does not necessarily indicate the issue. Would be useful to see the error is probably related to HTTPS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10706) Update spring-security-core to 5.7.4
[ https://issues.apache.org/jira/browse/NIFI-10706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-10706. - Resolution: Fixed > Update spring-security-core to 5.7.4 > > > Key: NIFI-10706 > URL: https://issues.apache.org/jira/browse/NIFI-10706 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.18.0 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Update spring-security-core to 5.7.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10696) Update Netty to 4.1.84.Final
[ https://issues.apache.org/jira/browse/NIFI-10696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-10696. - Resolution: Fixed > Update Netty to 4.1.84.Final > > > Key: NIFI-10696 > URL: https://issues.apache.org/jira/browse/NIFI-10696 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.18.0 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Update Netty to 4.1.84.Final -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10332) Add ID_TOKEN_LOGOUT support for general OpenID connect server, e.g. Keycloak
[
https://issues.apache.org/jira/browse/NIFI-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624778#comment-17624778
]
Nathan Gough commented on NIFI-10332:
-
Looking at this, it seems that a total refactor of the OIDC code would be a
great step forward for both the login and logout code and make things simpler.
I believe we are planning to migrate to using Spring to handle OIDC Auth
eventually.
Having said that, to fix this right now we could potentially check that the
discovery document contains either a revocation_endpoint and/or an
end_session_endpoint, and make decisions based on that. Currently the OIDC code
is checking for the Google domain to determine whether we need to make an
outgoing request for an access token and then use that access token to revoke
access. It looks like technically we should retrieve an id_token and
access_token all up front (Google provides both), instead of requesting it only
on logout, however in the case of Google the access token only has a 1 hour
lifetime. The combinations of tokens that can be retrieved are also varied:
[https://darutk.medium.com/diagrams-of-all-the-openid-connect-flows-6968e3990660].
Is there a well defined way to determine logout method that I am missing? I'm
not sure what auth flow Google is using that requires an access token to be
used to revoke access instead of using the ID token.
> Add ID_TOKEN_LOGOUT support for general OpenID connect server, e.g. Keycloak
>
>
> Key: NIFI-10332
> URL: https://issues.apache.org/jira/browse/NIFI-10332
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
>Affects Versions: 1.17.0
> Environment: NiFi 1.17.0, Keycloak 18.0.1
>Reporter: macdoor615
>Assignee: Nathan Gough
>Priority: Major
> Attachments: image-2022-08-09-16-56-25-791.png
>
>
> I deploy a NiFi 1.170 and authenticate with OpenID connect. Authentication
> server is Keycloak 18.0.1.
> I can log in and I can use UI properly.
> But when I logout. I get an error, can not redirect to NiFi UI or keycloak
> login UI
> !image-2022-08-09-16-56-25-791.png|width=782,height=347!
> [https://36.133.55.100:8943/realms/zznode/protocol/openid-connect/logout?post_logout_redirect_uri=https%3A%2F%2F36.138.166.203%3A18089%2Fhb3-dmz-repos-000-nifi%2Fnifi-api%2F..%2Fnifi%2Flogout-complete]
> I made some investigation into source code. I found NiFi only support
> ID_TOKEN_LOGOUT for okta service. Keycloak and other Authentication server
> can not be supported.
> Keycloak say it is compliance OpenID connect spec.
> I modified a few lines of source code. Let it support ID_TOKEN_LOGOUT for
> keycloak. Now I can log out NiFi and redirect to keycloak login UI, and than
> login NiFi again.
> I suggest making nifi to support ID_TOKEN_LOGOUT in later version for general
> OpenID connect server.
> I modified the file,
> [https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/OIDCAccessResource.java]
> start from line 403
> {code:java}
> private String determineLogoutMethod(String oidcDiscoveryUrl) {
> Matcher accessTokenMatcher =
> REVOKE_ACCESS_TOKEN_LOGOUT_FORMAT.matcher(oidcDiscoveryUrl);
> Matcher idTokenMatcher =
> ID_TOKEN_LOGOUT_FORMAT.matcher(oidcDiscoveryUrl);
>
> if (accessTokenMatcher.find()) {
> return REVOKE_ACCESS_TOKEN_LOGOUT;
> } else {
> return ID_TOKEN_LOGOUT;
> }
> }
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10700) Synchronizer incorrectly restarting Ports
[ https://issues.apache.org/jira/browse/NIFI-10700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10700: Fix Version/s: 1.19.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Synchronizer incorrectly restarting Ports > - > > Key: NIFI-10700 > URL: https://issues.apache.org/jira/browse/NIFI-10700 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 1.19.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Synchronizer should only reschedule Ports when their scheduledState is not > Running. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10589) Retry Relationships no sending to nifi-registry on commit
[ https://issues.apache.org/jira/browse/NIFI-10589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624158#comment-17624158 ] Nathan Gough commented on NIFI-10589: - This is interesting, I tested this in NiFi/NiFi Registry on NiFi 1.17.0 and on the main branch (unreleased NiFI 1.19.0) and do not see the issue. The retry relationships are being stored and retrieved correctly when I follow the sequence of operations shown in the attached screenshots. I am not using Docker for either NiFi or NiFi Registry which I don't suspect would be the cause, but is there possibly some other conditions that could be causing the issue? > Retry Relationships no sending to nifi-registry on commit > - > > Key: NIFI-10589 > URL: https://issues.apache.org/jira/browse/NIFI-10589 > Project: Apache NiFi > Issue Type: Bug > Components: Configuration, NiFi Registry >Affects Versions: 1.17.0, 1.18.0 > Environment: docker >Reporter: Yohany Flores >Priority: Critical > Attachments: ksnip_20221004-103903.png, ksnip_20221004-103959.png, > ksnip_20221004-104021.png, ksnip_20221004-104036.png, > ksnip_20221004-104047.png, ksnip_20221004-104101.png, > ksnip_20221004-104112.png, ksnip_20221004-104124.png, > ksnip_20221004-104136.png, ksnip_20221004-104150.png, > ksnip_20221004-104202.png > > > When configuring in any processor the RelationShips Tab with retry > information, it is not transmitted to the nifi-registry. > A simple Process Group, which is configured with Retry Relationship, is sent > to the nifi-registry. When the process group is imported from the > nifi-registry the retry information is not present in the new process group. > I am using > nifi-registry 1.17 > nifi 1.17 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10503) GenerateTableFetch processor has multiple references to "flow file" instead of "FlowFile"
[ https://issues.apache.org/jira/browse/NIFI-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-10503. - Fix Version/s: 1.19.0 Resolution: Fixed > GenerateTableFetch processor has multiple references to "flow file" instead > of "FlowFile" > - > > Key: NIFI-10503 > URL: https://issues.apache.org/jira/browse/NIFI-10503 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI, Documentation & Website >Reporter: Andrew M. Lim >Assignee: Andrew M. Lim >Priority: Trivial > Fix For: 1.19.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The property "Output Empty FlowFile on Zero Results" has the description: > Depending on the specified properties, an execution of this processor may not > result in any SQL statements generated. When this property is true, an empty > *flow file* will be generated (having the parent of the incoming *flow file* > if present) and transferred to the 'success' relationship. "When this > property is false, no output *flow files* will be generated. > Additionally, the usage docs has this in the description: > "Generates SQL select queries that fetch "pages" of rows from a table. The > partition size property, along with the table's row count, determine the size > and number of pages and generated FlowFiles. In addition, incremental > fetching can be achieved by setting Maximum-Value Columns, which causes the > processor to track the columns' maximum values, thus only fetching rows whose > columns' values exceed the observed maximums. This processor is intended to > be run on the Primary Node only. This processor can accept incoming > connections; the behavior of the processor is different whether incoming > connections are provided: - If no incoming connection(s) are specified, the > processor will generate SQL queries on the specified processor schedule. > Expression Language is supported for many fields, but no *flow file* > attributes are available. However the properties will be evaluated using the > Variable Registry. - If incoming connection(s) are specified and no *flow > file* is available to a processor task, no work will be performed. - If > incoming connection(s) are specified and a *flow file* is available to a > processor task, the *flow file's* attributes may be used in Expression > Language for such fields as Table Name and others. However, the Max-Value > Columns and Columns to Return fields must be empty or refer to columns that > are available in each specified table." > and this in the Additional Details: > "GenerateTableFetch uses its properties and the specified database connection > to generate *flow files* containing SQL statements that can be used..." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-9437) Flowfile Expiration does not exceed 24 days
[ https://issues.apache.org/jira/browse/NIFI-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-9437: --- Fix Version/s: 1.19.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Flowfile Expiration does not exceed 24 days > --- > > Key: NIFI-9437 > URL: https://issues.apache.org/jira/browse/NIFI-9437 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.14.0, 1.15.0 >Reporter: Tim Chermak >Assignee: Timea Barna >Priority: Minor > Fix For: 1.19.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We discovered setting a FlowFile Expiration on a queue for anything over 24 > days is ignored and not 'aged out of the flow". So, if FlowFile Expiration is > set to anything beyond 24 days, the file does not automatically expire and > remains in the queue. > > Can this be fixed so that there is no limit? Also, perhaps the Expiration > setting can have other criteria/strategy for expiring, as indicated in an old > ticket NiFi-372 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-10332) Add ID_TOKEN_LOGOUT support for general OpenID connect server, e.g. Keycloak
[
https://issues.apache.org/jira/browse/NIFI-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough reassigned NIFI-10332:
---
Assignee: Nathan Gough
> Add ID_TOKEN_LOGOUT support for general OpenID connect server, e.g. Keycloak
>
>
> Key: NIFI-10332
> URL: https://issues.apache.org/jira/browse/NIFI-10332
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
>Affects Versions: 1.17.0
> Environment: NiFi 1.17.0, Keycloak 18.0.1
>Reporter: macdoor615
>Assignee: Nathan Gough
>Priority: Major
> Attachments: image-2022-08-09-16-56-25-791.png
>
>
> I deploy a NiFi 1.170 and authenticate with OpenID connect. Authentication
> server is Keycloak 18.0.1.
> I can log in and I can use UI properly.
> But when I logout. I get an error, can not redirect to NiFi UI or keycloak
> login UI
> !image-2022-08-09-16-56-25-791.png|width=782,height=347!
> [https://36.133.55.100:8943/realms/zznode/protocol/openid-connect/logout?post_logout_redirect_uri=https%3A%2F%2F36.138.166.203%3A18089%2Fhb3-dmz-repos-000-nifi%2Fnifi-api%2F..%2Fnifi%2Flogout-complete]
> I made some investigation into source code. I found NiFi only support
> ID_TOKEN_LOGOUT for okta service. Keycloak and other Authentication server
> can not be supported.
> Keycloak say it is compliance OpenID connect spec.
> I modified a few lines of source code. Let it support ID_TOKEN_LOGOUT for
> keycloak. Now I can log out NiFi and redirect to keycloak login UI, and than
> login NiFi again.
> I suggest making nifi to support ID_TOKEN_LOGOUT in later version for general
> OpenID connect server.
> I modified the file,
> [https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/OIDCAccessResource.java]
> start from line 403
> {code:java}
> private String determineLogoutMethod(String oidcDiscoveryUrl) {
> Matcher accessTokenMatcher =
> REVOKE_ACCESS_TOKEN_LOGOUT_FORMAT.matcher(oidcDiscoveryUrl);
> Matcher idTokenMatcher =
> ID_TOKEN_LOGOUT_FORMAT.matcher(oidcDiscoveryUrl);
>
> if (accessTokenMatcher.find()) {
> return REVOKE_ACCESS_TOKEN_LOGOUT;
> } else {
> return ID_TOKEN_LOGOUT;
> }
> }
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10546) Commons HttpClient 3.1 has reached EOL. Need to upgrade it
[
https://issues.apache.org/jira/browse/NIFI-10546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622539#comment-17622539
]
Nathan Gough commented on NIFI-10546:
-
The commons-httpclient dependency only exists in NiFi as a transitive
dependency in old processors, for example hive_1_1:
{code:java}
[INFO] --- maven-dependency-plugin:3.3.0:tree (default-cli) @
nifi-hive_1_1-processors ---
[INFO] org.apache.nifi:nifi-hive_1_1-processors:jar:1.19.0-SNAPSHOT
[INFO] \- org.apache.hive.hcatalog:hive-hcatalog-streaming:jar:1.1.1:compile
[INFO] \- org.apache.hive:hive-exec:jar:1.1.1:compile
[INFO] \- commons-httpclient:commons-httpclient:jar:3.0.1:compile
{code}
There is a long term plan to completely deprecate these processors in NiFi 2.0,
but for now they can be removed from NiFi's lib/ directory manually if they are
not required.
> Commons HttpClient 3.1 has reached EOL. Need to upgrade it
> ---
>
> Key: NIFI-10546
> URL: https://issues.apache.org/jira/browse/NIFI-10546
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Core UI
>Affects Versions: 1.17.0, 1.16.3, 1.18.0
>Reporter: Vrinda Palod
>Priority: Critical
>
> Please upgrade the Commons HttpClient 3.1 to latest version in below
> locations.
>
>
> |/nifidata/apps/nifi_binary/work/nar/extensions/nifi-hbase_1_1_2-client-service-nar-1.16.3.nar-unpacked/NAR-INF/bundled-dependencies/commons-httpclient-3.1.jar|
> |/nifidata/apps/nifi_binary/work/nar/extensions/nifi-hive-nar-1.16.3.nar-unpacked/NAR-INF/bundled-dependencies/commons-httpclient-3.0.1.jar|
> |/nifidata/apps/nifi_binary/work/nar/framework/nifi-framework-nar-1.16.3.nar-unpacked/NAR-INF/bundled-dependencies/commons-httpclient-3.1.jar|
> |/nifidata/apps/nifi_toolkit_binary/lib/commons-httpclient-3.1.jar|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10664) Could not read from StandardFlowFileRecord in nifi
[ https://issues.apache.org/jira/browse/NIFI-10664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-10664. - Resolution: Duplicate > Could not read from StandardFlowFileRecord in nifi > -- > > Key: NIFI-10664 > URL: https://issues.apache.org/jira/browse/NIFI-10664 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.16.3 >Reporter: Vrinda Palod >Priority: Critical > > Hi Team, > > We are continuously getting this error at random interval of time. We are not > able to figure out from which flow/Process group this error is coming. Need > help in moving further > > org.apache.nifi.processor.exception.FlowFileAccessException: Could not read > from StandardFlowFileRecord[uuid=*,claim=,offset=0,name=*,size=0] > org.apache.nifi.processor.exception.FlowFileAccessException: Could not read > from StandardFlowFileRecord[uuid=*,claim=,offset=0,name=*,size=0] at > org.apache.nifi.controller.repository.io.FlowFileAccessInputStream.read(FlowFileAccessInputStream.java:93) > at > org.apache.nifi.controller.repository.io.FlowFileAccessInputStream.read(FlowFileAccessInputStream.java:99) > at > org.apache.nifi.controller.repository.io.TaskTerminationInputStream.read(TaskTerminationInputStream.java:62) > at org.apache.nifi.stream.io.StreamUtils.copy(StreamUtils.java:35) at > org.apache.nifi.processors.standard.ExecuteStreamCommand$2run(ExecuteStreamCommand.java:634) > at java.base/java.lang.Thread.run(Thread.java:834) Caused by: > java.io.IOException: Stream is closed at > org.apache.nifi.controller.repository.io.DisableOnCloseInputStream.checkClosed(DisableOnCloseInputStream.java:65) > at > org.apache.nifi.controller.repository.io.DisableOnCloseInputStream.read(DisableOnCloseInputStream.java:48) > at > org.apache.nifi.stream.io.ByteCountingInputStream.read(ByteCountingInputStream.java:52) > at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133) at > org.apache.nifi.controller.repository.io.FlowFileAccessInputStream.read(FlowFileAccessInputStream.java:82) > ... 5 common frames omitted -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10667) Add Private Key Controller Service
[
https://issues.apache.org/jira/browse/NIFI-10667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10667:
Fix Version/s: 1.19.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add Private Key Controller Service
> --
>
> Key: NIFI-10667
> URL: https://issues.apache.org/jira/browse/NIFI-10667
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.19.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> A new Controller Service enabling abstracted access to Private Keys should be
> implemented to support Processors and Services that require cryptographic
> Private Keys.
> The service should support returning instances of
> {{{}java.security.PrivateKey{}}}. The service should be capable of reading
> encrypted or unencrypted private keys encoded using the
> [PEM|https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail] format and
> structured using [PKCS 8|https://en.wikipedia.org/wiki/PKCS_8]. The PEM
> format represents encoded key material using Base64, so the service should be
> configurable using either a file path or a sensitive property where the key
> can be specified as a property value.
> With {{java.security.PrivateKey}} being part as the standard JDK, this
> service interface is suitable for inclusion in the
> {{{}nifi-standard-services-api-nar{}}}, which will also enable future custom
> implementations from other sources.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-10672) Remove unreliable test testGetDataSourceIdleProperties from DBCPServiceTest
Nathan Gough created NIFI-10672:
---
Summary: Remove unreliable test testGetDataSourceIdleProperties
from DBCPServiceTest
Key: NIFI-10672
URL: https://issues.apache.org/jira/browse/NIFI-10672
Project: Apache NiFi
Issue Type: Test
Affects Versions: 1.18.0
Reporter: Nathan Gough
Test is having intermittent failure:
{code:java}
[INFO] Running org.apache.nifi.lookup.TestRecordSetWriterLookup
[ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.684
s <<< FAILURE! - in org.apache.nifi.dbcp.DBCPServiceTest
[ERROR] org.apache.nifi.dbcp.DBCPServiceTest.testGetDataSourceIdleProperties
Time elapsed: 0.308 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
at
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at
org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
at
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
at
org.apache.nifi.dbcp.DBCPServiceTest.testGetDataSourceIdleProperties(DBCPServiceTest.java:283)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10662) Upgrade Jackson to 2.13.4.20221013
[ https://issues.apache.org/jira/browse/NIFI-10662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10662: Fix Version/s: 1.19.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Jackson to 2.13.4.20221013 > -- > > Key: NIFI-10662 > URL: https://issues.apache.org/jira/browse/NIFI-10662 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.19.0 > > Time Spent: 1h > Remaining Estimate: 0h > > The Jackson Bill of Materials dependency 2.13.4.20221013 upgrades Jackson > dependencies to 2.13.4.2, which resolves > [CVE-2022-42003|https://nvd.nist.gov/vuln/detail/CVE-2022-42003] present in > 2.13.4. This micro-version upgrade appears to be the best path forward while > the 2.14 version is still in release candidate status. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10595) Merged Set-Cookie Values
[ https://issues.apache.org/jira/browse/NIFI-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619631#comment-17619631 ] Nathan Gough commented on NIFI-10595: - My guess is that this is the fault of the java.net.CookieManager which InvokeHTTP uses, meaning it's likely a Java problem. I'm also not sure if there's a great workaround as, like you say, NiFi won't allow you to set two HTTP request headers with the same name. > Merged Set-Cookie Values > > > Key: NIFI-10595 > URL: https://issues.apache.org/jira/browse/NIFI-10595 > Project: Apache NiFi > Issue Type: Wish > Components: Core Framework >Affects Versions: 1.17.0 > Environment: docker pull nifi > Running in docker environment > DefectDojo-> NiFi -> Jira >Reporter: michael endrizzi >Priority: Critical > Attachments: cookie.jpg, duplicate.jpg, image001.png, image003.jpg, > image004.jpg > > > App A generates multiple Set-Cookie attributes > > Set-Cookie: JSESSIONID=332A0702B579B2C2E978F156CA2D2CA2; Path=/; HttpOnly > X-Seraph-LoginReason: OK > Set-Cookie: > atlassian.xsrf.token=BG2A-03LA-WE1W-P6YO_eb6999a3eeebf8ac3daa9d048e5434f70636849f_lin; > Path=/ > > and NiFi merges the cookie values into a single line > > Set-Cookie: JSESSIONID=332A0702B579B2C2E978F156CA2D2CA2; Path=/; HttpOnly, > atlassian.xsrf.token=BG2A-03LA-WE1W-P6YO_eb6999a3eeebf8ac3daa9d048e5434f70636849f_lin; > Path=/ > > Unfortunately, applications do not all like this format. Seems to violate > standards: > https://httpd.apache.org/docs/2.0/misc/known_client_problems.html#cookie-merge > > In addition, NiFi does not allow you to manually add a second duplicate > header (see attached) > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10625) Add HTTP/2 Support to Registry Server
[
https://issues.apache.org/jira/browse/NIFI-10625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10625:
Fix Version/s: 1.19.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add HTTP/2 Support to Registry Server
> -
>
> Key: NIFI-10625
> URL: https://issues.apache.org/jira/browse/NIFI-10625
> Project: Apache NiFi
> Issue Type: Improvement
> Components: NiFi Registry
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.19.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The {{nifi-jetty-configuration}} module includes shared configuration
> capabilities that support HTTP/2 in the NiFi Application Server,
> HandleHttpRequest, and ListenHTTP. This shared configuration should be
> extended to NiFi Registry in order to support enabling HTTP/2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10635) Enum in Avro schema not working in PutDatabaseRecord
[
https://issues.apache.org/jira/browse/NIFI-10635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10635:
Fix Version/s: 1.19.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Enum in Avro schema not working in PutDatabaseRecord
>
>
> Key: NIFI-10635
> URL: https://issues.apache.org/jira/browse/NIFI-10635
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Jonathan Keller
>Assignee: Matt Burgess
>Priority: Major
> Fix For: 1.19.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There appears to be a regression in the PutDatabaseRecord processor with
> 1.13.0 (works in 1.12.1)
> I have an Avro schema for a record which contained enum fields. After
> upgrading, a processor which had been working was failing on errors, stating
> it could not find the record type. The field in question is defined as below.
> The files which were erroring out were the exact same files, and no changes
> had been made to the schema or the CSV reader controller between the tests.
> I was also able to successfully move the flow.xml.gz file back to the older
> version of NiFi and the PutDatabaseRecord processor was able to work again to
> insert the database records.
> {noformat}
> {
> "name": "PER_ORG",
> "type": {
> "type": "enum",
> "name": "PerOrgFlag",
> "symbols": [
> "EMP",
> "CWR"
> ]
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10648) Upgrade Commons Text to 1.10.0
[
https://issues.apache.org/jira/browse/NIFI-10648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10648:
Fix Version/s: 1.19.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Upgrade Commons Text to 1.10.0
> --
>
> Key: NIFI-10648
> URL: https://issues.apache.org/jira/browse/NIFI-10648
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.19.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Apache Commons Text versions prior to 1.10.0 are vulnerable to
> [CVE-2022-42889|https://nvd.nist.gov/vuln/detail/CVE-2022-42889], which
> involves potential script execution when processing untrusted input using
> {{StringLookup}}. Direct and transitive references to Apache Commons Text
> prior to 1.10.0 should be upgraded to avoid the default interpolation
> behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10640) Extra dropdown when configuring controller services
[ https://issues.apache.org/jira/browse/NIFI-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10640: Description: I may have missed some new feature that was added, but I'm not sure what this extra dropdown box below 'reference parameter' is supposed to do.. as far as I can tell it's a bug that's occurring when no controller services exist yet and goes away when a controller service is created. A javascript error is shown in the console: !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! was: I may have missed some new feature that was added, but I'm not sure what this extra dropdown box below 'reference parameter' is supposed to do.. as far as I can tell it's a bug that's occurring when existing no controller services exist and goes away when a controller service is created. A javascript error is shown in the console: !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! > Extra dropdown when configuring controller services > --- > > Key: NIFI-10640 > URL: https://issues.apache.org/jira/browse/NIFI-10640 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.19.0 >Reporter: Nathan Gough >Priority: Major > Attachments: Screen Shot 2022-10-13 at 7.37.42 PM.png > > > I may have missed some new feature that was added, but I'm not sure what this > extra dropdown box below 'reference parameter' is supposed to do.. as far as > I can tell it's a bug that's occurring when no controller services exist yet > and goes away when a controller service is created. A javascript error is > shown in the console: > !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10640) Extra dropdown when configuring controller services
[ https://issues.apache.org/jira/browse/NIFI-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10640: Description: I may have missed some new feature that was added, but I'm not sure what this extra dropdown box below 'reference parameter' is supposed to do.. as far as I can tell it's a bug that's occurring when existing no controller services exist and goes away when a controller service is created. A javascript error is shown in the console: !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! was: I may have missed some new feature that was added, but I'm not sure what this extra dropdown box below 'reference parameter' is supposed to do, but there appears to be a javascript error of some kind: !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! Summary: Extra dropdown when configuring controller services (was: Extra dropdown for some processors 'controller service' properties?) > Extra dropdown when configuring controller services > --- > > Key: NIFI-10640 > URL: https://issues.apache.org/jira/browse/NIFI-10640 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.19.0 >Reporter: Nathan Gough >Priority: Major > Attachments: Screen Shot 2022-10-13 at 7.37.42 PM.png > > > I may have missed some new feature that was added, but I'm not sure what this > extra dropdown box below 'reference parameter' is supposed to do.. as far as > I can tell it's a bug that's occurring when existing no controller services > exist and goes away when a controller service is created. A javascript error > is shown in the console: > !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10640) Extra dropdown for some processors 'controller service' properties?
[ https://issues.apache.org/jira/browse/NIFI-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10640: Description: I may have missed some new feature that was added, but I'm not sure what this extra dropdown box below 'reference parameter' is supposed to do, but there appears to be a javascript error of some kind: !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! was: I may have missed some new feature that was added, but I'm not sure what this extra dropdown box in this modal is supposed to do, but there appears to be a javascript error of some kind: !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! > Extra dropdown for some processors 'controller service' properties? > --- > > Key: NIFI-10640 > URL: https://issues.apache.org/jira/browse/NIFI-10640 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.19.0 >Reporter: Nathan Gough >Priority: Major > Attachments: Screen Shot 2022-10-13 at 7.37.42 PM.png > > > I may have missed some new feature that was added, but I'm not sure what this > extra dropdown box below 'reference parameter' is supposed to do, but there > appears to be a javascript error of some kind: > !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10640) Extra dropdown for some processors 'controller service' properties?
[ https://issues.apache.org/jira/browse/NIFI-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10640: Description: I may have missed some new feature that was added, but I'm not sure what this extra dropdown box in this modal is supposed to do, but there appears to be a javascript error of some kind: !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! was: I may have missed some new feature that was added, but I'm not sure what this extra dropdown box in this modal is supposed to do, but there appears to be a javascript error of some kind: !Screen Shot 2022-10-13 at 7.37.42 PM.png! > Extra dropdown for some processors 'controller service' properties? > --- > > Key: NIFI-10640 > URL: https://issues.apache.org/jira/browse/NIFI-10640 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.19.0 >Reporter: Nathan Gough >Priority: Major > Attachments: Screen Shot 2022-10-13 at 7.37.42 PM.png > > > I may have missed some new feature that was added, but I'm not sure what this > extra dropdown box in this modal is supposed to do, but there appears to be a > javascript error of some kind: > !Screen Shot 2022-10-13 at 7.37.42 PM.png|width=1267,height=888! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10640) Extra dropdown for some processors 'controller service' properties?
Nathan Gough created NIFI-10640: --- Summary: Extra dropdown for some processors 'controller service' properties? Key: NIFI-10640 URL: https://issues.apache.org/jira/browse/NIFI-10640 Project: Apache NiFi Issue Type: Bug Components: Core UI Affects Versions: 1.19.0 Reporter: Nathan Gough Attachments: Screen Shot 2022-10-13 at 7.37.42 PM.png I may have missed some new feature that was added, but I'm not sure what this extra dropdown box in this modal is supposed to do, but there appears to be a javascript error of some kind: !Screen Shot 2022-10-13 at 7.37.42 PM.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10576) ParquetRecordSetWriter doesn't write avro schema
[ https://issues.apache.org/jira/browse/NIFI-10576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616617#comment-17616617 ] Nathan Gough commented on NIFI-10576: - This appears to be an issue also in NiFi 1.18, so I have submitted a PR which should now add the avro schema as an attribute like XMLRecordSetWriter does. > ParquetRecordSetWriter doesn't write avro schema > > > Key: NIFI-10576 > URL: https://issues.apache.org/jira/browse/NIFI-10576 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.15.2 >Reporter: DEOM Damien >Assignee: Nathan Gough >Priority: Critical > > ParquetRecordSetWrite ignores Set 'avro.schema' Attribute option -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (NIFI-10576) ParquetRecordSetWriter doesn't write avro schema
[ https://issues.apache.org/jira/browse/NIFI-10576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616617#comment-17616617 ] Nathan Gough edited comment on NIFI-10576 at 10/12/22 5:50 PM: --- This appears to be an issue also in NiFi 1.18, so I have submitted a PR which should now add the avro schema as an attribute like XMLRecordSetWriter does: https://github.com/apache/nifi/pull/6517 was (Author: thenatog): This appears to be an issue also in NiFi 1.18, so I have submitted a PR which should now add the avro schema as an attribute like XMLRecordSetWriter does. > ParquetRecordSetWriter doesn't write avro schema > > > Key: NIFI-10576 > URL: https://issues.apache.org/jira/browse/NIFI-10576 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.15.2 >Reporter: DEOM Damien >Assignee: Nathan Gough >Priority: Critical > > ParquetRecordSetWrite ignores Set 'avro.schema' Attribute option -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10569) Add Maximum Threads to HandleHttpRequest
[
https://issues.apache.org/jira/browse/NIFI-10569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10569:
Fix Version/s: 1.19.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add Maximum Threads to HandleHttpRequest
>
>
> Key: NIFI-10569
> URL: https://issues.apache.org/jira/browse/NIFI-10569
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.19.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The {{HandleHttpRequest}} Processor runs an embedded Jetty Server that uses a
> configurable number of threads for handling HTTP requests and responses.
> Similar to changes for {{ListenHTTP}}, the {{HandleHttpRequest}} Processor
> should have a property for configuring the maximum number of threads for the
> Jetty Server. The Jetty internal defaults have a minimum of {{8}}, and use
> {{200}} in absence of a specific number.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10605) Add idle timeout property to ListenTCP
[ https://issues.apache.org/jira/browse/NIFI-10605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-10605. - Resolution: Duplicate Accidentally submitted create form twice? > Add idle timeout property to ListenTCP > -- > > Key: NIFI-10605 > URL: https://issues.apache.org/jira/browse/NIFI-10605 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > > Add a time property to ListenTCP to allow idle client connections to be > closed by the server. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10604) Add idle timeout property to ListenTCP
Nathan Gough created NIFI-10604: --- Summary: Add idle timeout property to ListenTCP Key: NIFI-10604 URL: https://issues.apache.org/jira/browse/NIFI-10604 Project: Apache NiFi Issue Type: Improvement Reporter: Nathan Gough Assignee: Nathan Gough Add a time property to ListenTCP to allow idle client connections to be closed by the server. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10605) Add idle timeout property to ListenTCP
Nathan Gough created NIFI-10605: --- Summary: Add idle timeout property to ListenTCP Key: NIFI-10605 URL: https://issues.apache.org/jira/browse/NIFI-10605 Project: Apache NiFi Issue Type: Improvement Reporter: Nathan Gough Assignee: Nathan Gough Add a time property to ListenTCP to allow idle client connections to be closed by the server. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (NIFI-10595) Merged Set-Cookie Values
[ https://issues.apache.org/jira/browse/NIFI-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613242#comment-17613242 ] Nathan Gough edited comment on NIFI-10595 at 10/6/22 6:47 PM: -- Hi Michael, could we please have more details on what you're trying to achieve, and what specifically the issue is when the cookie is merged? What error are you seeing on the application side? My understanding is that you're trying to do the following: # An application makes a request to NiFi (HandleHTTPRequest) with two Set-Cookie headers # The cookies are implicitly merged by NiFi # You are unable to respond to the application using HandleHTTPResponse because the cookie headers are merged, and there's no way to set these headers separately again as shown in duplicate.jpg was (Author: thenatog): Hi Michael, could we please have more details on what you're trying to achieve, and what specifically the issue is when the cookie is merged? What error are you seeing on the application side? My understanding is that you're trying to do the following: # An application makes a request to NiFi (HandleHTTPRequest) it responds with two Set-Cookie headers # The cookies are implicitly merged by NiFi # You are unable to respond to the application using HandleHTTPResponse because the cookie headers are merged, and there's no way to set these headers separately again as shown in duplicate.jpg > Merged Set-Cookie Values > > > Key: NIFI-10595 > URL: https://issues.apache.org/jira/browse/NIFI-10595 > Project: Apache NiFi > Issue Type: Wish > Components: Core Framework >Affects Versions: 1.17.0 > Environment: docker pull nifi > Running in docker environment > DefectDojo-> NiFi -> Jira >Reporter: michael endrizzi >Priority: Critical > Attachments: cookie.jpg, duplicate.jpg > > > App A generates multiple Set-Cookie attributes > > Set-Cookie: JSESSIONID=332A0702B579B2C2E978F156CA2D2CA2; Path=/; HttpOnly > X-Seraph-LoginReason: OK > Set-Cookie: > atlassian.xsrf.token=BG2A-03LA-WE1W-P6YO_eb6999a3eeebf8ac3daa9d048e5434f70636849f_lin; > Path=/ > > and NiFi merges the cookie values into a single line > > Set-Cookie: JSESSIONID=332A0702B579B2C2E978F156CA2D2CA2; Path=/; HttpOnly, > atlassian.xsrf.token=BG2A-03LA-WE1W-P6YO_eb6999a3eeebf8ac3daa9d048e5434f70636849f_lin; > Path=/ > > Unfortunately, applications do not all like this format. Seems to violate > standards: > https://httpd.apache.org/docs/2.0/misc/known_client_problems.html#cookie-merge > > In addition, NiFi does not allow you to manually add a second duplicate > header (see attached) > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10586) Prioritize ssh-rsa Key Algorithm in SFTP Processors
[
https://issues.apache.org/jira/browse/NIFI-10586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10586:
Fix Version/s: 1.19.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Prioritize ssh-rsa Key Algorithm in SFTP Processors
> ---
>
> Key: NIFI-10586
> URL: https://issues.apache.org/jira/browse/NIFI-10586
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.17.0, 1.16.1
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.19.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> SSHJ 0.33.0 included changes to depend on the Key Algorithms configuration
> property to determine supported RSA algorithms for public key authentication.
> [SSHJ PR 742|https://github.com/hierynomus/sshj/pull/742] standardized this
> configuration, which prioritizes {{rsa-sha2-256}} and {{rsa-sha2-512}} before
> the legacy {{ssh-rsa}} algorithm. [SSHJ PR
> 763|https://github.com/hierynomus/sshj/pull/763] introduced additional
> changes to try all configured RSA algorithms, but it depends on the server
> indicating support for retrying public key authentication after initial
> failures.
> To maintain wider compatibility, the Apache NiFi SSH default configuration
> should be adjusted to prioritize {{ssh-rsa}} before {{rsa-sha2}} algorithms,
> using the method implemented in SSHJ 0.33.0 PR 742. This prioritization
> should be enabled in the default SFTP Processor configuration where the {{Key
> Algorithms Allowed}} property is not specified. Overriding the {{Key
> Algorithms Allowed}} property should continue to support custom algorithm and
> selection with defined prioritization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-10595) Merged Set-Cookie Values
[ https://issues.apache.org/jira/browse/NIFI-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613242#comment-17613242 ] Nathan Gough commented on NIFI-10595: - Hi Michael, could we please have more details on what you're trying to achieve, and what specifically the issue is when the cookie is merged? What error are you seeing on the application side? My understanding is that you're trying to do the following: # An application makes a request to NiFi (HandleHTTPRequest) it responds with two Set-Cookie headers # The cookies are implicitly merged by NiFi # You are unable to respond to the application using HandleHTTPResponse because the cookie headers are merged, and there's no way to set these headers separately again as shown in duplicate.jpg > Merged Set-Cookie Values > > > Key: NIFI-10595 > URL: https://issues.apache.org/jira/browse/NIFI-10595 > Project: Apache NiFi > Issue Type: Wish > Components: Core Framework >Affects Versions: 1.17.0 > Environment: docker pull nifi > Running in docker environment > DefectDojo-> NiFi -> Jira >Reporter: michael endrizzi >Priority: Critical > Attachments: cookie.jpg, duplicate.jpg > > > App A generates multiple Set-Cookie attributes > > Set-Cookie: JSESSIONID=332A0702B579B2C2E978F156CA2D2CA2; Path=/; HttpOnly > X-Seraph-LoginReason: OK > Set-Cookie: > atlassian.xsrf.token=BG2A-03LA-WE1W-P6YO_eb6999a3eeebf8ac3daa9d048e5434f70636849f_lin; > Path=/ > > and NiFi merges the cookie values into a single line > > Set-Cookie: JSESSIONID=332A0702B579B2C2E978F156CA2D2CA2; Path=/; HttpOnly, > atlassian.xsrf.token=BG2A-03LA-WE1W-P6YO_eb6999a3eeebf8ac3daa9d048e5434f70636849f_lin; > Path=/ > > Unfortunately, applications do not all like this format. Seems to violate > standards: > https://httpd.apache.org/docs/2.0/misc/known_client_problems.html#cookie-merge > > In addition, NiFi does not allow you to manually add a second duplicate > header (see attached) > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-10576) ParquetRecordSetWriter doesn't write avro schema
[ https://issues.apache.org/jira/browse/NIFI-10576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough reassigned NIFI-10576: --- Assignee: Nathan Gough > ParquetRecordSetWriter doesn't write avro schema > > > Key: NIFI-10576 > URL: https://issues.apache.org/jira/browse/NIFI-10576 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.15.2 >Reporter: DEOM Damien >Assignee: Nathan Gough >Priority: Critical > > ParquetRecordSetWrite ignores Set 'avro.schema' Attribute option -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-9637) GCP Secret Manager Parameter Provider
[ https://issues.apache.org/jira/browse/NIFI-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-9637. Fix Version/s: 1.19.0 Resolution: Fixed > GCP Secret Manager Parameter Provider > - > > Key: NIFI-9637 > URL: https://issues.apache.org/jira/browse/NIFI-9637 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Joe Gresock >Assignee: Joe Gresock >Priority: Minor > Fix For: 1.19.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Once NIFI-9003 is complete, a Parameter Provider backed by GCP Secret Manager > could be written. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-9451) Add Input Character Set Property to PutEmail
[
https://issues.apache.org/jira/browse/NIFI-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough resolved NIFI-9451.
Fix Version/s: 1.18.0
Resolution: Fixed
> Add Input Character Set Property to PutEmail
>
>
> Key: NIFI-9451
> URL: https://issues.apache.org/jira/browse/NIFI-9451
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: Emilio Setiadarma
>Priority: Minor
> Fix For: 1.18.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> The {{PutEmail}} processor supports reading input FlowFile contents to
> generate the message body, or as an attachment to the message. In both cases,
> the processor uses the UTF-8 character set to read the input FlowFile in
> preparation for message encoding.
> A new property should be added to {{PutEmail}} named {{Input Character Set}}
> that would support the ability to configure the character set when reading
> FlowFile contents. The default value should be {{UTF-8}} to maintain
> compatibility with the current implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10534) Upgrade spring.version to 5.3.23
[ https://issues.apache.org/jira/browse/NIFI-10534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-10534. - Fix Version/s: 1.18.0 Resolution: Fixed > Upgrade spring.version to 5.3.23 > > > Key: NIFI-10534 > URL: https://issues.apache.org/jira/browse/NIFI-10534 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.17.0 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Fix For: 1.18.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Upgrade spring.version to 5.3.23 from 5.3.22 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-10534) Upgrade spring.version to 5.3.23
[ https://issues.apache.org/jira/browse/NIFI-10534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough reassigned NIFI-10534: --- Assignee: Mike R > Upgrade spring.version to 5.3.23 > > > Key: NIFI-10534 > URL: https://issues.apache.org/jira/browse/NIFI-10534 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.17.0 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Upgrade spring.version to 5.3.23 from 5.3.22 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10525) Upgrade apache-hadoop dependency version
Nathan Gough created NIFI-10525: --- Summary: Upgrade apache-hadoop dependency version Key: NIFI-10525 URL: https://issues.apache.org/jira/browse/NIFI-10525 Project: Apache NiFi Issue Type: Improvement Affects Versions: 1.17.0 Reporter: Nathan Gough Assignee: Nathan Gough Upgrade apache-hadoop to 3.3.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-10492) Upgrade graphics2d to 0.40
[ https://issues.apache.org/jira/browse/NIFI-10492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-10492. - Fix Version/s: 1.18.0 Resolution: Fixed > Upgrade graphics2d to 0.40 > -- > > Key: NIFI-10492 > URL: https://issues.apache.org/jira/browse/NIFI-10492 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.17.0 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Fix For: 1.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Upgrade graphics2d to 0.40 from 0.32 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-10492) Upgrade graphics2d to 0.40
[ https://issues.apache.org/jira/browse/NIFI-10492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough reassigned NIFI-10492: --- Assignee: Mike R > Upgrade graphics2d to 0.40 > -- > > Key: NIFI-10492 > URL: https://issues.apache.org/jira/browse/NIFI-10492 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.17.0 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Upgrade graphics2d to 0.40 from 0.32 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10484) Upgrade OWASP Dependency Check Plugin to 7.1.2
[ https://issues.apache.org/jira/browse/NIFI-10484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10484: Fix Version/s: 1.18.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade OWASP Dependency Check Plugin to 7.1.2 > -- > > Key: NIFI-10484 > URL: https://issues.apache.org/jira/browse/NIFI-10484 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The OWASP Dependency Check Plugin version 7.1.2 includes several minor bug > fixes and updates to avoid false positive notifications for various libraries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10407) Intermittent Failures in GetSmbFileTest
[
https://issues.apache.org/jira/browse/NIFI-10407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10407:
Fix Version/s: 1.18.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Intermittent Failures in GetSmbFileTest
> ---
>
> Key: NIFI-10407
> URL: https://issues.apache.org/jira/browse/NIFI-10407
> Project: Apache NiFi
> Issue Type: Bug
> Components: Tools and Build
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.18.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The {{GetSmbFileTest}} class fails intermittently in automated builds on
> Windows for {{testBatchSize}} with the following assertion mismatch:
> {noformat}
> Error: org.apache.nifi.processors.smb.GetSmbFileTest.testBatchSize Time
> elapsed: 0.063 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <20> but was: <10>
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
> at
> org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
> at
> org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at
> org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:527)
> at
> org.apache.nifi.util.StandardProcessorTestRunner.assertTransferCount(StandardProcessorTestRunner.java:360)
> at
> org.apache.nifi.processors.smb.GetSmbFileTest.testBatchSize(GetSmbFileTest.java:284)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10384) Upgrade Avatica to 1.22.0 for Hive 3
[ https://issues.apache.org/jira/browse/NIFI-10384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10384: Fix Version/s: 1.18.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Avatica to 1.22.0 for Hive 3 > > > Key: NIFI-10384 > URL: https://issues.apache.org/jira/browse/NIFI-10384 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 1.18.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Hive 3.1.3 incorporates a transitive dependency on Avatica 1.11.0, which > bundles shaded versions of several libraries, such as Jackson and Apache > HttpClient. Avatica 1.22.0 includes updated versions of these shaded > libraries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10408) Include user value when an LDAP error occurs during startup
[ https://issues.apache.org/jira/browse/NIFI-10408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10408: Fix Version/s: 1.18.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Include user value when an LDAP error occurs during startup > --- > > Key: NIFI-10408 > URL: https://issues.apache.org/jira/browse/NIFI-10408 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Wynner >Assignee: David Handermann >Priority: Minor > Labels: Authorization, LDAP, NiFi, ldap.conf > Fix For: 1.18.0 > > Time Spent: 40m > Remaining Estimate: 0h > > > ERROR org.springframework.web.context.ContextLoader: Context initialization > failed > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name > 'org.springframework.security.config.annotation.web.configuration.WebSecurityConfiguration': > Unsatisfied dependency expressed through method > 'setFilterChainProxySecurityConfigurer' parameter 1; nested exception is > org.springframework.beans.factory.BeanExpressionException: Expression parsing > failed; nested exception is > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name > 'org.apache.nifi.web.NiFiWebApiSecurityConfiguration': Unsatisfied dependency > expressed through method 'setJwtAuthenticationProvider' parameter 0; nested > exception is org.springframework.beans.factory.BeanCreationException: Error > creating bean with name 'jwtAuthenticationProvider' defined in class path > resource [nifi-web-security-context.xml]: Cannot resolve reference to bean > 'authorizer' while setting constructor argument; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'authorizer': FactoryBean threw exception on object creation; > nested exception is java.lang.IllegalArgumentException: Identity can not be > null or empty > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10313) Unexpected "Access Token not found"
[ https://issues.apache.org/jira/browse/NIFI-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10313: Fix Version/s: 1.18.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Unexpected "Access Token not found" > --- > > Key: NIFI-10313 > URL: https://issues.apache.org/jira/browse/NIFI-10313 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Malthe Borch >Assignee: David Handermann >Priority: Major > Fix For: 1.18.0 > > Attachments: NiFi-Errors.PNG, authorizers.xml, nifi.log > > Time Spent: 40m > Remaining Estimate: 0h > > I'm experiencing some unexpected "Access Token not found" errors after > upgrading to 1.17.0. > See attached traceback. > What happens is that the NiFi UI seems to work but after a short while the > view is redirected to a conflict page (Unable to communicate with NiFi). > There are no other problems or evidence of the issue to be found in the logs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10321) Improve Expired JWT Error Message Wording
[
https://issues.apache.org/jira/browse/NIFI-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10321:
Fix Version/s: 1.18.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Improve Expired JWT Error Message Wording
> -
>
> Key: NIFI-10321
> URL: https://issues.apache.org/jira/browse/NIFI-10321
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
>Affects Versions: 1.17.0
> Environment: CentOS 8, NIFI 1.17.0, Keycloak 19.0.1
>Reporter: macdoor615
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.18.0
>
> Attachments: 截屏2022-08-05 13.31.47.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I follow
> [https://bryanbende.com/development/2021/02/17/apache-nifi-saml-keycloak] to
> config nifi 1.17.0. NIFI can login successful with SAML Authentication with
> Keycloak 19.0.1. But when nifi times out with SAML session. NIFI UI gives the
> following error.
> {code:java}
> Unauthorized error="invalid_token", error_description="An error occurred
> while attempting to decode the Jwt: Expired JWT",
> error_uri="https://tools.ietf.org/html/rfc6750#section-3.1"{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10348) Upgrade Tomcat Embed to 8.5.82 for Flume Processors
[ https://issues.apache.org/jira/browse/NIFI-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10348: Fix Version/s: 1.18.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Tomcat Embed to 8.5.82 for Flume Processors > --- > > Key: NIFI-10348 > URL: https://issues.apache.org/jira/browse/NIFI-10348 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 1.18.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Apache Flume Processors have a transitive dependency on Apache Tomcat Embed > Core 8.5.46, which has several associated vulnerabilities. Although most of > these vulnerabilities relate to Apache Tomcat Server, upgrading a more recent > version of the library includes several bug fixes and resolves false > positives. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10350) Registry User Actions not authorized with OpenID Connect
[
https://issues.apache.org/jira/browse/NIFI-10350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10350:
Fix Version/s: 1.18.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Registry User Actions not authorized with OpenID Connect
>
>
> Key: NIFI-10350
> URL: https://issues.apache.org/jira/browse/NIFI-10350
> Project: Apache NiFi
> Issue Type: Bug
> Components: NiFi Registry
>Affects Versions: 1.16.0, 1.17.0
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.18.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> NiFi Registry users that should be authorized to add users and change
> policies are unable to make changes through the user interface after
> authenticating with OpenID Connect.
> From a new installation of NiFI Registry integrated with an OpenID Connect
> provider, the {{Add User}} button is disabled for the {{Initial Admin
> Identity}} configured in the {{file-access-policy-provider}} properties.
> Evaluating HTTP requests and responses, NiFi Registry makes an initial
> request to {{/nifi-registry-api/config}} and receives an HTTP 401
> Unauthorized response for the unauthenticated anonymous user. After selecting
> {{Login}} and authenticating with the OpenID Connect provider, the {{Add
> User}} button remains disabled.
> The problem is that the user interface does not refresh the Registry
> Configuration after a successful OIDC login. The Registry Configuration
> indicates whether the Registry Authorizer is configurable, which controls
> whether the {{Add User}} button is disabled. Authentication with username and
> password credentials using Kerberos or LDAP works based on a subsequent
> request to {{/nifi-registry-api/config}} after a successful login.
> The user interface should be modified to refresh the Registry Configuration
> following a successful OIDC login.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10368) Upgrade jQuery UI to 1.13.2
[
https://issues.apache.org/jira/browse/NIFI-10368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10368:
Fix Version/s: 1.18.0
> Upgrade jQuery UI to 1.13.2
> ---
>
> Key: NIFI-10368
> URL: https://issues.apache.org/jira/browse/NIFI-10368
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Labels: dependency-upgrade
> Fix For: 1.18.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The jQuery UI library before version 1.13.2 has an XSS vulnerability
> described in [CVE-2022-31160|https://nvd.nist.gov/vuln/detail/CVE-2022-31160].
> Although Apache NiFi does not make direct use of the vulnerable
> {{checkboxradio()}} function, upgrading jQuery UI to 1.13.2 mitigates
> potential issues and moves away from version 1.12.1, which is no longer
> supported.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10368) Upgrade jQuery UI to 1.13.2
[
https://issues.apache.org/jira/browse/NIFI-10368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10368:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Upgrade jQuery UI to 1.13.2
> ---
>
> Key: NIFI-10368
> URL: https://issues.apache.org/jira/browse/NIFI-10368
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Labels: dependency-upgrade
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The jQuery UI library before version 1.13.2 has an XSS vulnerability
> described in [CVE-2022-31160|https://nvd.nist.gov/vuln/detail/CVE-2022-31160].
> Although Apache NiFi does not make direct use of the vulnerable
> {{checkboxradio()}} function, upgrading jQuery UI to 1.13.2 mitigates
> potential issues and moves away from version 1.12.1, which is no longer
> supported.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10322) invalid_token error after OpenID connect session timeout
[
https://issues.apache.org/jira/browse/NIFI-10322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10322:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> invalid_token error after OpenID connect session timeout
>
>
> Key: NIFI-10322
> URL: https://issues.apache.org/jira/browse/NIFI-10322
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core UI
>Affects Versions: 1.17.0
>Reporter: macdoor615
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.18.0
>
> Attachments: image-2022-08-05-22-48-17-835.png,
> image-2022-08-05-22-48-52-057.png, image-2022-08-07-14-28-09-058.png,
> image-2022-08-07-15-22-36-213.png, image-2022-08-07-15-27-18-902.png,
> image-2022-08-07-15-37-29-739.png, image-2022-08-07-15-43-14-922.png,
> image-2022-08-07-15-47-57-158.png, image-2022-08-07-15-53-47-220.png,
> image-2022-08-07-16-00-11-443.png, image-2022-08-07-16-11-38-180.png,
> image-2022-08-08-23-33-30-220.png, image-2022-08-08-23-35-02-773.png,
> image-2022-08-08-23-59-12-471.png, nginx-access.log.zip,
> nifi-1.16.3-logs.zip, nifi-1.17.0-logs.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I follow
> [https://bryanbende.com/development/2017/10/03/apache-nifi-openid-connect] to
> config NIFI 1.16.3 and it is work properly. If the session times out, login
> again and it will work again
> I configured 1.17.0 in the same way. I can login and operate nifi UI. But
> when session times out. I got the following error.
>
> {code:java}
> Unauthorized error="invalid_token", error_description="An error occurred
> while attempting to decode the Jwt: Expired JWT",
> error_uri="https://tools.ietf.org/html/rfc6750#section-3.1"{code}
>
> !image-2022-08-05-22-48-17-835.png|width=758,height=108!
> I try to login again and get a new error, and I cannot enter the NIFI
> interface.
>
> {code:java}
> Unauthorized error="invalid_token", error_description="An error occurred
> while attempting to decode the Jwt: Signed JWT rejected: Another algorithm
> expected, or no matching key(s) found",
> error_uri="https://tools.ietf.org/html/rfc6750#section-3.1"{code}
>
> !image-2022-08-05-22-48-52-057.png|width=594,height=143!
> I did some research, and found
> After the session times out,
> NIFI 1.16.3 leaves 3 cookies in browser:
> * nifi-logout-request-identifier
> * nifi-oidc-request-identifier
> * __Secure-Request-Token
> NIFI 1.17.0 leaves 2 cookies:
> * *__Secure-Authorization-Bearer*
> * __Secure-Request-Token
> __Secure-Authorization-Bearer cookie contains a expired JWT:
> {code:java}
> eyJraWQiOiJhMDlhZDhlMy0xZDkzLTQyZTEtYjg0Ni0xMWU0ODRkODYwYWYiLCJhbGciOiJQUzUxMiJ9.eyJzdWIiOiJhZG1pbi5uaWZpQGd1bWhiMy5jb20iLCJhdWQiOiJodHRwcyUzQSUyRiUyRjM2LjEzMy41NS4xMDAlM0E4OTQzJTJGcmVhbG1zJTJGenpub2RlIiwibmJmIjoxNjU5NjExOTc0LCJpc3MiOiJodHRwcyUzQSUyRiUyRjM2LjEzMy41NS4xMDAlM0E4OTQzJTJGcmVhbG1zJTJGenpub2RlIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYWRtaW4ubmlmaUBndW1oYjMuY29tIiwiZXhwIjoxNjU5NjEyMjc0LCJpYXQiOjE2NTk2MTE5NzQsImp0aSI6IjFiZTg5MjU4LTliZmYtNDhmOS04OGNmLWU0NDIzMDZjYzg4ZCJ9.Y9yE0hNH_q-W94_cFWOWGc7TPMP2xB9coaSRPT9twYqSyjTtudOiiXGxHEDUWsOvUFf7lT7wNH4RZ_LhOM-5WfTZ3o-DCVFnl0JjeZ-L9d-z3rO4dEspRxXpr46AewEGy_lpstSUFyihr4i8b2VI7IT0aFOCGAIXRWl7gfH75e5La_0tbsu9lgSRdyYBBv8rSjojJC5bBSqxj-BkrfjdMhyMuF9OdMCJNmyh18BrXbavwftNerytkd_Qf9eNLmzsZ3SOdKWpftKt4kClD_KeL0nOglhM-ENyb4QLwxr7l5lhUgQ-2am3x5okbRyYip_WV4YQ6DfmUnLL1FYFATWXa5CUimSRbSZzkqU2JEYerpvKsTf-prdsSNryPbrQdf5HqpwhlGbFrgm4jwtncZHTLEL4ZMciVe0H-zIcQ9vyDqamMpf6fyNWmQN8DdDP9A0Zpo7SL7yhOUjNGsjk1gV4OAHWgp4XQzj4KwoGf7ICjeOrzinECHFZw9Ccyi8KMooRx4u3oAuKPEx3mrZFNFDaiAzWX0kZ31c24-15cno2bLBMGOIx7ipjb6Pv7V6O9S2aA2vC3eVLnfAgHAox3I8_IzWLUKddHCqd6cfA1XW8ckSgg2QddKvgYHiCZpwVV4AMDpK4bI1J0ZbxbgOOke9IMMudNhZUFQdWJIXh-gx1bII{code}
> I manually delete __Secure-Authorization-Bearer cookie, and I can login NIFI
> 1.17.0 again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10217) Refactor Deprecated Usage of WebSecurityConfigurerAdapter in Registry
[
https://issues.apache.org/jira/browse/NIFI-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10217:
Fix Version/s: 1.18.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Refactor Deprecated Usage of WebSecurityConfigurerAdapter in Registry
> -
>
> Key: NIFI-10217
> URL: https://issues.apache.org/jira/browse/NIFI-10217
> Project: Apache NiFi
> Issue Type: Improvement
> Components: NiFi Registry, Security
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.18.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Spring Security 5.7.0 deprecated {{WebSecurityConfigurerAdapter}} in favor of
> configuring a {{SecurityFilterChain}}. The NiFi Registry Spring Security
> Configuration should updated to avoid extending the deprecated class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-10319) Upgrade Calcite Core To 1.31.0
[ https://issues.apache.org/jira/browse/NIFI-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough resolved NIFI-10319. - Fix Version/s: 1.18.0 Resolution: Fixed > Upgrade Calcite Core To 1.31.0 > -- > > Key: NIFI-10319 > URL: https://issues.apache.org/jira/browse/NIFI-10319 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Mike R >Priority: Major > Fix For: 1.18.0 > > Time Spent: 40m > Remaining Estimate: 0h > > There are several different versions of calcite-core being used in the > environment, all of which have a lot of vulnerabilities that 1.31.0 doesnt > have -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10301) Align Apache Fluent HttpClient with Standard HttpClient Version
[ https://issues.apache.org/jira/browse/NIFI-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10301: Fix Version/s: 1.18.0 > Align Apache Fluent HttpClient with Standard HttpClient Version > --- > > Key: NIFI-10301 > URL: https://issues.apache.org/jira/browse/NIFI-10301 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Trivial > Labels: dependency-upgrade > Fix For: 1.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The root Maven configuration specifies a managed dependency version for > Apache HttpComponents HttpClient, currently version 4.5.13. The Fluent > HttpClient library depends on the standard HttpClient version, so the Fluent > HttpClient dependency version should be aligned to avoid runtime conflicts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10301) Align Apache Fluent HttpClient with Standard HttpClient Version
[ https://issues.apache.org/jira/browse/NIFI-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10301: Resolution: Fixed Status: Resolved (was: Patch Available) > Align Apache Fluent HttpClient with Standard HttpClient Version > --- > > Key: NIFI-10301 > URL: https://issues.apache.org/jira/browse/NIFI-10301 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Trivial > Labels: dependency-upgrade > Time Spent: 0.5h > Remaining Estimate: 0h > > The root Maven configuration specifies a managed dependency version for > Apache HttpComponents HttpClient, currently version 4.5.13. The Fluent > HttpClient library depends on the standard HttpClient version, so the Fluent > HttpClient dependency version should be aligned to avoid runtime conflicts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10259) Improve Error Handling for Invalid JWT Bearer Tokens
[
https://issues.apache.org/jira/browse/NIFI-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10259:
Fix Version/s: 1.17.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Improve Error Handling for Invalid JWT Bearer Tokens
>
>
> Key: NIFI-10259
> URL: https://issues.apache.org/jira/browse/NIFI-10259
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Core UI, Security
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.17.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The default failure handler for Bearer Token authentication returns the
> {{WWW-Authenticate}} HTTP response header for invalid tokens, but does not
> include any response body. When user interface provides the Bearer Token in a
> Cookie header, the failure handler does not remove cookie. This behavior
> should be updated to return the error parameters in the response body and
> return a Set-Cookie header that instructs the browser to remove the cookie.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10233) Correct Anonymous Authentication for HTTP Access
[
https://issues.apache.org/jira/browse/NIFI-10233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10233:
Fix Version/s: 1.17.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Correct Anonymous Authentication for HTTP Access
>
>
> Key: NIFI-10233
> URL: https://issues.apache.org/jira/browse/NIFI-10233
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.17.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Refactoring the NiFi Spring Security configuration added a check to determine
> whether application properties allowed anonymous authentication. The
> {{nifi.security.allow.anoymous.authentication}} property is {{false}} in the
> default configuration, but the changing the property should not be necessary
> when configuring HTTP without TLS.
> The Spring Security configuration should be adjusted to restore current
> behavior, which enables anonymous authentication when configuring unencrypted
> HTTP.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-10232) Improve netty pool handling in NettyDistributedMapCacheClient
Nathan Gough created NIFI-10232: --- Summary: Improve netty pool handling in NettyDistributedMapCacheClient Key: NIFI-10232 URL: https://issues.apache.org/jira/browse/NIFI-10232 Project: Apache NiFi Issue Type: Improvement Reporter: Nathan Gough Assignee: Nathan Gough The DistributedMapCacheClient/CacheClientChannelPoolFactory used by the DistributedMapCacheClientService could use some improvements to avoid issues with hanging on close. This currently leaves the controller service in a DISABLING state either indefinitely or too long. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10216) Refactor Deprecated Usage of WebSecurityConfigurerAdapter
[
https://issues.apache.org/jira/browse/NIFI-10216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10216:
Fix Version/s: 1.17.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Refactor Deprecated Usage of WebSecurityConfigurerAdapter
> -
>
> Key: NIFI-10216
> URL: https://issues.apache.org/jira/browse/NIFI-10216
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI, Security
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 1.17.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Spring Security 5.7.0 deprecated {{WebSecurityConfigurerAdapter}} in favor of
> configuring a {{SecurityFilterChain}}. The NiFi Web API Security
> Configuration should be refactored to avoid deprecation warnings and follow
> the updated configuration strategy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10163) StandardProcessSession.exportTo() not tracking bytes read
[
https://issues.apache.org/jira/browse/NIFI-10163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Gough updated NIFI-10163:
Fix Version/s: 1.17.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> StandardProcessSession.exportTo() not tracking bytes read
> -
>
> Key: NIFI-10163
> URL: https://issues.apache.org/jira/browse/NIFI-10163
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.16.3
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 1.17.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The {{StandardProcessSession.exportTo(FlowFile, OutputStream)}} method does
> not increment the bytes read or bytes written properties after processing
> completes. Although the method uses a {{ByteCountingInputStream}}, the method
> does not use the accumulated bytes read.
> As a result of this issue, Processors that use this {{exportTo()}} method do
> not show any information in the {{Bytes Read}} and {{Bytes Transferred}}
> sections of the Processor Status History.
> This impacts {{InvokeHTTP}} and {{HandleHttpResponse}} among others.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-10158) ListFTP required field can not use Variable Registry.
[ https://issues.apache.org/jira/browse/NIFI-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Gough updated NIFI-10158: Fix Version/s: 1.17.0 Resolution: Fixed Status: Resolved (was: Patch Available) > ListFTP required field can not use Variable Registry. > -- > > Key: NIFI-10158 > URL: https://issues.apache.org/jira/browse/NIFI-10158 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.16.1, 1.16.2, 1.16.3 >Reporter: Hadi >Assignee: David Handermann >Priority: Minor > Fix For: 1.17.0 > > Attachments: image-2022-06-23-15-04-46-410.png, > image-2022-06-23-15-05-04-912.png, image-2022-06-24-14-13-08-220.png, > image-2022-06-24-14-13-34-266.png, image-2022-06-28-11-53-02-861.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > !image-2022-06-23-15-04-46-410.png! > !image-2022-06-23-15-05-04-912.png! > 1.16.X port field cant use variable registry, but 1.15.X can. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-9849) Refactor SAML 2 Support using Spring Security 5
Title: Message Title Nathan Gough updated NIFI-9849 Apache NiFi / NIFI-9849 Refactor SAML 2 Support using Spring Security 5 Change By: Nathan Gough Resolution: Fixed Status: Patch Available Resolved Add Comment This message was sent by Atlassian Jira (v8.20.10#820010-sha1:ace47f9)
[jira] [Updated] (NIFI-9849) Refactor SAML 2 Support using Spring Security 5
Title: Message Title Nathan Gough updated an issue Apache NiFi / NIFI-9849 Refactor SAML 2 Support using Spring Security 5 Change By: Nathan Gough Fix Version/s: 1.17.0 Add Comment This message was sent by Atlassian Jira (v8.20.10#820010-sha1:ace47f9)
