[jira] [Commented] (NIFI-10158) ListFTP required field can not use Variable Registry.

2022-06-23 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17557920#comment-17557920
 ] 

humpfhumpf commented on NIFI-10158:
---

The exception means that the value cannot be parsed into Java Long.

Could you verify that the value of your variable does not contain an extra 
space character?

> 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
>Priority: Minor
> Attachments: image-2022-06-23-15-04-46-410.png, 
> image-2022-06-23-15-05-04-912.png
>
>
> !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.7#820007)


[jira] [Commented] (NIFI-8836) Logout causes NullPointerException and continutes to display resources anonymous should not see

2021-11-23 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-8836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17447884#comment-17447884
 ] 

humpfhumpf commented on NIFI-8836:
--

I agree: after an incomplete logout (see 
https://issues.apache.org/jira/browse/NIFI-9406), the UI shows both "anonymous" 
as current username and the list of buckets.

> Logout causes NullPointerException and continutes to display resources 
> anonymous should not see
> ---
>
> Key: NIFI-8836
> URL: https://issues.apache.org/jira/browse/NIFI-8836
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: NiFi Registry
>Reporter: Chris Sampson
>Assignee: Nathan Gough
>Priority: Major
>
> After configuring OIDC login through NiFi Registry UI (which I note appears 
> to need an explicit click of the {{Login}} button in the UI rather than 
> automatically logging the user in like NiFi UI), I see the following 
> behaviour:
> * {{Login}} via OIDC (link in UI)
> * Display list of buckets (to which {{anonymous}} users do not have access)
> * {{Logout}} (link in UI)
> * See the below log from NiFi Registry
> * Note that the buckets are still displayed in the UI for the {{anonymous}} 
> user
> {code:java}
> 2021-02-15 17:10:48,374 ERROR [NiFi Registry Web Server-18] 
> o.a.n.r.web.mapper.ThrowableMapper An unexpected error has occurred: 
> java.lang.NullPointerException. Returning Internal Server Error response.
> java.lang.NullPointerException: null
>   at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
>   at java.util.regex.Matcher.reset(Matcher.java:309)
>   at java.util.regex.Matcher.(Matcher.java:229)
>   at java.util.regex.Pattern.matcher(Pattern.java:1093)
>   at 
> org.apache.nifi.registry.web.security.authentication.jwt.JwtService.getTokenFromHeader(JwtService.java:238)
>   at 
> org.apache.nifi.registry.web.security.authentication.jwt.JwtService.logOutUsingAuthHeader(JwtService.java:233)
>   at 
> org.apache.nifi.registry.web.api.AccessResource.oidcLogout(AccessResource.java:708)
>   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$VoidOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:159)
>   at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
>   at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:469)
>   at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:391)
>   at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:80)
>   at 
> org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:253)
>   at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
>   at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
>   at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
>   at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
>   at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
>   at 
> org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
>   at 
> org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
>   at 
> org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
>   at 
> org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:392)
>   at 
> org.glassfish.jersey.servlet.ServletContainer.serviceImpl(ServletContainer.java:385)
>   at 
> org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:560)
>   at 
> org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:501)
>   at 
> org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:438)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> 

[jira] [Updated] (NIFI-9406) Registry logout with OIDC redirects to HTTP DELETE

2021-11-23 Thread humpfhumpf (Jira)


 [ 
https://issues.apache.org/jira/browse/NIFI-9406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

humpfhumpf updated NIFI-9406:
-
Affects Version/s: 0.8.0

> Registry logout with OIDC redirects to HTTP DELETE
> --
>
> Key: NIFI-9406
> URL: https://issues.apache.org/jira/browse/NIFI-9406
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: NiFi Registry
>Affects Versions: 0.8.0, 1.13.2
>Reporter: humpfhumpf
>Priority: Major
>
> When NiFi Registry is configured with OIDC authentification, the logout link 
> redirects to the logout URL of the Identity Provider (Keycloack in my case) 
> with HTTP *DELETE* method, instead of {*}GET{*}.
> NiFi Registry shows an error box : "Please contact your System Administrator."
> NiFi does not have this bug.
> +Network calls :+
>  * DELETE 
> [https://revproxy/nifi-registry/logout|https://proxy-nifi-registry-zds1.admin.artemis/nifi-registry/logout]
>  ** HTTP 302 ("redirect")
>  * OPTIONS 
> [https://revproxy/auth/realms/myrealm/protocol/openid-connect/logout?post_logout_redirect_uri=https://revproxy/nifi-registry-api/../nifi-registry]
>  * 
>  ** HTTP 204 (No Content)
>  * DELETE 
> [https://revproxy/auth/realms/myrealm/protocol/openid-connect/logout?post_logout_redirect_uri=https://revproxy/nifi-registry-api/../nifi-registry]
>  ** HTTP 405 (Method not allowed)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Created] (NIFI-9406) Registry logout with OIDC redirects to HTTP DELETE

2021-11-23 Thread humpfhumpf (Jira)
humpfhumpf created NIFI-9406:


 Summary: Registry logout with OIDC redirects to HTTP DELETE
 Key: NIFI-9406
 URL: https://issues.apache.org/jira/browse/NIFI-9406
 Project: Apache NiFi
  Issue Type: Bug
  Components: NiFi Registry
Affects Versions: 1.13.2
Reporter: humpfhumpf


When NiFi Registry is configured with OIDC authentification, the logout link 
redirects to the logout URL of the Identity Provider (Keycloack in my case) 
with HTTP *DELETE* method, instead of {*}GET{*}.

NiFi Registry shows an error box : "Please contact your System Administrator."

NiFi does not have this bug.

+Network calls :+
 * DELETE 
[https://revproxy/nifi-registry/logout|https://proxy-nifi-registry-zds1.admin.artemis/nifi-registry/logout]
 ** HTTP 302 ("redirect")
 * OPTIONS 
[https://revproxy/auth/realms/myrealm/protocol/openid-connect/logout?post_logout_redirect_uri=https://revproxy/nifi-registry-api/../nifi-registry]

 * 
 ** HTTP 204 (No Content)
 * DELETE 
[https://revproxy/auth/realms/myrealm/protocol/openid-connect/logout?post_logout_redirect_uri=https://revproxy/nifi-registry-api/../nifi-registry]
 ** HTTP 405 (Method not allowed)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Comment Edited] (NIFI-8607) UpdateAttribute Advanced Button displaying prompt outside dialog screen

2021-09-22 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418557#comment-17418557
 ] 

humpfhumpf edited comment on NIFI-8607 at 9/22/21, 12:08 PM:
-

Sorry, I mixed with already solved issue : 
https://issues.apache.org/jira/browse/NIFI-7870

--

Previous message :

Same problem hier with 1.13.2 (and java 11). It does not depend on cache, but 
on anonymous authentication.

The cause is *401 errors when accessing *.js and *.css* on this advanced UI, 
and others "sisters" UI, like content-viewer.

In my case, the error message is "*Anonymous authentication has not been 
configured.*"

The stacktrace shows :

{{2021-09-22 12:40:28,315 INFO [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter Attempting request for () GET 
[https://hostname.com/nifi-content-viewer/js/hexview/hexview.js] (source ip: 
x.x.x.x)}}
 {{2021-09-22 12:40:28,316 WARN [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter Rejecting access to web api: Anonymous 
authentication has not been configured.}}
 {{2021-09-22 12:40:28,334 DEBUG [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter}}
 {{org.apache.nifi.web.security.InvalidAuthenticationException: Anonymous 
authentication has not been configured.}}
 \{{ at 
org.apache.nifi.web.security.anonymous.NiFiAnonymousAuthenticationProvider.authenticate(NiFiAnonymousAuthenticationProvider.java:46)}}

 

nifi.properties contains :

{{nifi.security.allow.anonymous.authentication=false}}


was (Author: humpfhumpf):
Sorry, I mixed with already solved issue : 
https://issues.apache.org/jira/browse/NIFI-7870

Same problem hier with 1.13.2 (and java 11). It does not depend on cache, but 
on anonymous authentication.

The cause is *401 errors when accessing *.js and *.css* on this advanced UI, 
and others "sisters" UI, like content-viewer.

In my case, the error message is "*Anonymous authentication has not been 
configured.*"

The stacktrace shows :

{{2021-09-22 12:40:28,315 INFO [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter Attempting request for () GET 
[https://hostname.com/nifi-content-viewer/js/hexview/hexview.js] (source ip: 
x.x.x.x)}}
 {{2021-09-22 12:40:28,316 WARN [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter Rejecting access to web api: Anonymous 
authentication has not been configured.}}
 {{2021-09-22 12:40:28,334 DEBUG [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter}}
 {{org.apache.nifi.web.security.InvalidAuthenticationException: Anonymous 
authentication has not been configured.}}
 \{{ at 
org.apache.nifi.web.security.anonymous.NiFiAnonymousAuthenticationProvider.authenticate(NiFiAnonymousAuthenticationProvider.java:46)}}

 

nifi.properties contains :

{{nifi.security.allow.anonymous.authentication=false}}

> UpdateAttribute Advanced Button displaying prompt outside dialog screen
> ---
>
> Key: NIFI-8607
> URL: https://issues.apache.org/jira/browse/NIFI-8607
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.13.2
> Environment: Centos 7. - MacOS
>Reporter: Phil
>Priority: Minor
> Attachments: Screen Shot 2021-05-26 at 9.20.07 PM.png, 
> image-2021-05-17-13-50-18-264.png, image-2021-05-17-13-50-59-978.png
>
>
> Works fine on  Windows 10 Both Chrome and Microsoft Edge
> {color:#FF} but NOT on macOS with Chrome or Safari{color}
> {color:#FF}Chrome Version 90.0.4430.212 (Official Build) (x86_64){color}
> {color:#FF}Safari Version 13.1.2 (13609.3.5.1.5){color}
> {color:#FF}macOS High Sierra 10.13.6{color}
>  
> Select Advanced
> !image-2021-05-17-13-50-18-264.png!
>  
> !image-2021-05-17-13-50-59-978.png!
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (NIFI-8607) UpdateAttribute Advanced Button displaying prompt outside dialog screen

2021-09-22 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418557#comment-17418557
 ] 

humpfhumpf edited comment on NIFI-8607 at 9/22/21, 12:07 PM:
-

Sorry, I mixed with already solved issue : 
https://issues.apache.org/jira/browse/NIFI-7870

Same problem hier with 1.13.2 (and java 11). It does not depend on cache, but 
on anonymous authentication.

The cause is *401 errors when accessing *.js and *.css* on this advanced UI, 
and others "sisters" UI, like content-viewer.

In my case, the error message is "*Anonymous authentication has not been 
configured.*"

The stacktrace shows :

{{2021-09-22 12:40:28,315 INFO [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter Attempting request for () GET 
[https://hostname.com/nifi-content-viewer/js/hexview/hexview.js] (source ip: 
x.x.x.x)}}
 {{2021-09-22 12:40:28,316 WARN [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter Rejecting access to web api: Anonymous 
authentication has not been configured.}}
 {{2021-09-22 12:40:28,334 DEBUG [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter}}
 {{org.apache.nifi.web.security.InvalidAuthenticationException: Anonymous 
authentication has not been configured.}}
 \{{ at 
org.apache.nifi.web.security.anonymous.NiFiAnonymousAuthenticationProvider.authenticate(NiFiAnonymousAuthenticationProvider.java:46)}}

 

nifi.properties contains :

{{nifi.security.allow.anonymous.authentication=false}}


was (Author: humpfhumpf):
Same problem hier with 1.13.2 (and java 11). It does not depend on cache, but 
on anonymous authentication.


The cause is *401 errors when accessing *.js and *.css* on this advanced UI, 
and others "sisters" UI, like content-viewer.

In my case, the error message is "*Anonymous authentication has not been 
configured.*"

The stacktrace shows :

{{2021-09-22 12:40:28,315 INFO [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter Attempting request for () GET 
https://hostname.com/nifi-content-viewer/js/hexview/hexview.js (source ip: 
x.x.x.x)}}
{{2021-09-22 12:40:28,316 WARN [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter Rejecting access to web api: Anonymous 
authentication has not been configured.}}
{{2021-09-22 12:40:28,334 DEBUG [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter}}
{{org.apache.nifi.web.security.InvalidAuthenticationException: Anonymous 
authentication has not been configured.}}
{{ at 
org.apache.nifi.web.security.anonymous.NiFiAnonymousAuthenticationProvider.authenticate(NiFiAnonymousAuthenticationProvider.java:46)}}

 

nifi.properties contains :

{{nifi.security.allow.anonymous.authentication=false}}

> UpdateAttribute Advanced Button displaying prompt outside dialog screen
> ---
>
> Key: NIFI-8607
> URL: https://issues.apache.org/jira/browse/NIFI-8607
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.13.2
> Environment: Centos 7. - MacOS
>Reporter: Phil
>Priority: Minor
> Attachments: Screen Shot 2021-05-26 at 9.20.07 PM.png, 
> image-2021-05-17-13-50-18-264.png, image-2021-05-17-13-50-59-978.png
>
>
> Works fine on  Windows 10 Both Chrome and Microsoft Edge
> {color:#FF} but NOT on macOS with Chrome or Safari{color}
> {color:#FF}Chrome Version 90.0.4430.212 (Official Build) (x86_64){color}
> {color:#FF}Safari Version 13.1.2 (13609.3.5.1.5){color}
> {color:#FF}macOS High Sierra 10.13.6{color}
>  
> Select Advanced
> !image-2021-05-17-13-50-18-264.png!
>  
> !image-2021-05-17-13-50-59-978.png!
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (NIFI-8607) UpdateAttribute Advanced Button displaying prompt outside dialog screen

2021-09-22 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418557#comment-17418557
 ] 

humpfhumpf commented on NIFI-8607:
--

Same problem hier with 1.13.2 (and java 11). It does not depend on cache, but 
on anonymous authentication.


The cause is *401 errors when accessing *.js and *.css* on this advanced UI, 
and others "sisters" UI, like content-viewer.

In my case, the error message is "*Anonymous authentication has not been 
configured.*"

The stacktrace shows :

{{2021-09-22 12:40:28,315 INFO [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter Attempting request for () GET 
https://hostname.com/nifi-content-viewer/js/hexview/hexview.js (source ip: 
x.x.x.x)}}
{{2021-09-22 12:40:28,316 WARN [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter Rejecting access to web api: Anonymous 
authentication has not been configured.}}
{{2021-09-22 12:40:28,334 DEBUG [NiFi Web Server-4451] 
o.a.n.w.s.NiFiAuthenticationFilter}}
{{org.apache.nifi.web.security.InvalidAuthenticationException: Anonymous 
authentication has not been configured.}}
{{ at 
org.apache.nifi.web.security.anonymous.NiFiAnonymousAuthenticationProvider.authenticate(NiFiAnonymousAuthenticationProvider.java:46)}}

 

nifi.properties contains :

{{nifi.security.allow.anonymous.authentication=false}}

> UpdateAttribute Advanced Button displaying prompt outside dialog screen
> ---
>
> Key: NIFI-8607
> URL: https://issues.apache.org/jira/browse/NIFI-8607
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.13.2
> Environment: Centos 7. - MacOS
>Reporter: Phil
>Priority: Minor
> Attachments: Screen Shot 2021-05-26 at 9.20.07 PM.png, 
> image-2021-05-17-13-50-18-264.png, image-2021-05-17-13-50-59-978.png
>
>
> Works fine on  Windows 10 Both Chrome and Microsoft Edge
> {color:#FF} but NOT on macOS with Chrome or Safari{color}
> {color:#FF}Chrome Version 90.0.4430.212 (Official Build) (x86_64){color}
> {color:#FF}Safari Version 13.1.2 (13609.3.5.1.5){color}
> {color:#FF}macOS High Sierra 10.13.6{color}
>  
> Select Advanced
> !image-2021-05-17-13-50-18-264.png!
>  
> !image-2021-05-17-13-50-59-978.png!
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (NIFI-3993) Upgrade embedded ZooKeeper version

2021-03-16 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302440#comment-17302440
 ] 

humpfhumpf commented on NIFI-3993:
--

Since NIFI-6733 (released with NiFi 1.11.1), Zookeeper was upgraded to 3.5.6. 
Currently, the latest Zookeeper bugfix on 3.5 branch is 3.5.9.

> Upgrade embedded ZooKeeper version
> --
>
> Key: NIFI-3993
> URL: https://issues.apache.org/jira/browse/NIFI-3993
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0
>Reporter: Mark Bean
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In a Cluster configuration, Nodes are periodically disconnected from the 
> Cluster, and then reconnected. These events correspond to the following error:
> ERROR [CommitProcessor:1] o.apache.zookeeper.server.NIOServerCnxn Unexpected 
> Exception:
> java.nio.channels.CancelledKeyException: null
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SectionKeyImpl.java:73)
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelctionKeyImpl.java:77)
> at 
> org.apache.zookeeper.server.NIOServerCnxn.sendBuffer(NIOServerCnxn.java:151)
> at 
> org.apache.zookeeper.server.NIOServerCnXn.sendResopnse(NIOServerCnxn.java:1081)
> at 
> org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:404)
> at 
> org.apache.zookeeper.server.quorum.CommitProcessor.run(CommitProcessor.java:74)
> This error was reported in ZooKeeper JIRA [1], and reported as fixed in 
> version 3.4.10, the current stable build. As additional confirmation, when 
> using a stand-alone ZK, 3.4.10, rather than the embedded ZK, the above error 
> was no longer observed.
> Update NiFi to use ZK 3.4.10
> [1] https://issues.apache.org/jira/browse/ZOOKEEPER-2044



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (NIFI-7263) Add a No tracking Strategy to ListFile/ListFTP

2021-01-20 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268565#comment-17268565
 ] 

humpfhumpf commented on NIFI-7263:
--

In our production case, files are available on SFTP server without 
chronological order. We want ListSFTP to list all available files, and 
FetchSFTP to move them on a remote directory, after getting them.

> Add a No tracking Strategy to ListFile/ListFTP
> --
>
> Key: NIFI-7263
> URL: https://issues.apache.org/jira/browse/NIFI-7263
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Jens M Kofoed
>Assignee: Waleed Al Aibani
>Priority: Major
>  Labels: ListFile, listftp
> Fix For: 1.13.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The Listfile/ListFTP has 2 Listing Strategies: Tracking Timestamps and 
> Tracking Entities.
> It would be very very nice if the List process also could have a No Tracking 
> (fix it your self) strategy
> If running NIFI in a cluster the List/Fetch is the perfect solution instead 
> of using a GetFile. But we have had many caces where files in the pickup 
> folder has old timestamps, so here we have to use Tracking Entities.
> The issue is in cases where you are not allowed to delete files but you have 
> to make a change to the file filter. The tracking entities start all over, 
> and list all files again.
> In other situations we need to resent all data, and would like to clear the 
> state of the Tracking Entities. But you can't.
> So I have to make a small flow for detecting duplicates. And in some cases 
> just ignore duplicates and in other caces open up for sending duplicates. But 
> it is a pain in the ... to use the Tracking Entities.
> So a NO STRATEGY would be very very nice



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (NIFI-8028) Cannot compile "SNAPSHOT" extention

2020-11-19 Thread humpfhumpf (Jira)
humpfhumpf created NIFI-8028:


 Summary: Cannot compile "SNAPSHOT" extention
 Key: NIFI-8028
 URL: https://issues.apache.org/jira/browse/NIFI-8028
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Affects Versions: 1.12.1, 1.12.0
Reporter: humpfhumpf


Since NIFI-7291, the master pom.xml forbids to compile an extension with 
version like "1.0-SNAPSHOT" (through `enforce-no-snapshots` rule).

The [Wiki 
page|https://cwiki.apache.org/confluence/display/NIFI/Maven+Projects+for+Extensions]
 should mention it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (NIFI-7771) Infinite loop on WebUI when node stopped in cluster

2020-11-18 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17234356#comment-17234356
 ] 

humpfhumpf commented on NIFI-7771:
--

thx [~mtien] for your confirmation, and +1.

> Infinite loop on WebUI when node stopped in cluster
> ---
>
> Key: NIFI-7771
> URL: https://issues.apache.org/jira/browse/NIFI-7771
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.10.0, 1.9.2, 1.12.0, 1.11.4
> Environment: Linux
>Reporter: humpfhumpf
>Assignee: M Tien
>Priority: Critical
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> h2. Context
> Before the bug occurs, one needs:
>  * a load-balancer which uses client IP affinity to “select” one NiFi 
> instance in the cluster;
>  * a fresh and successful OpenID Connect authentication on WebUI.
> Then, stops the NiFi instance, which was “selected” by the load-balancer for 
> you.
> In the mean time, the WebUI (javascript) continues to poll WebAPI by fetching 
> status URLs, but all calls return HTTP 401 error. Then WebUI shows an error 
> screen: “Unauthorized. Unable to validate the access token.”, with 2 links: 
> “log out” and “home”.
> If you click on the “home” link, *the browser enters in an infinite loop of 
> redirects between NiFi and OIDC Identity Provider.*
> The offending HTTP flows is:
>  * “home” link calls: GET /nifi
>  * Redirects to: GET /nifi/
>  ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
>  * Redirects to: GET /nifi/login
>  * Redirects to: GET /openid-connect/auth
>  * Redirects to: GET /nifi-api/access/oidc/callback
>  * Redirects to: GET /nifi
>  * Redirects to: GET /nifi/
>  ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
>  * [loop]
>  
> The stack trace of {{/nifi-api/flow/current-user}} call is:
>  
> {code:java}
> ERROR [NiFi Web Server-284] o.a.nifi.web.security.jwt.JwtService There was an 
> error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the 
> access token.
>      at 
> org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:106)
>      at 
> org.apache.nifi.web.security.jwt.JwtService.getAuthenticationFromToken(JwtService.java:60)
>      at 
> org.apache.nifi.web.security.jwt.JwtAuthenticationProvider.authenticate(JwtAuthenticationProvider.java:48)
>      at 
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:78)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
>      at 
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:99)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
>      ...
> Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match 
> locally computed signature. JWT validity cannot be asserted and should not be 
> trusted.
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:342)
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
>      at 
> org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:102)
>      ...
> {code}
>  
>  
> In my opinion, there are 2 problems:
> h2. Problem 1
> The NiFi JWT token is used (and not replaced) by nfCanvas.init() even after 
> loadCurrentUser() failed with an authentication error (when GET 
> /nifi-api/flow/current-user returns 401).
> In such case, this token, stored in nfStorage (in Javascript Local Storage of 
> browser), should be cleared before redirecting to /nifi/login.
> h2. Problem 2
> The NiFi JWT token is not shared among NiFi cluster.
> This token is not the original id_token returned by the OIDC Identity 
> Provider, but a new one, generated by the NiFi instance on which the browser 
> was routed during the OIDC connection flow.
> This token is closely related to some data stored in H2 users database 
> (nifi-user-keys.h2.db).
> Its “KEY” table contains the following data for each user: email, a primary 
> key (auto increment) and a generated UUID.
> The NiFi JWT token contains (among other things) a copy of email and the 
> auto-incremented primary key. Moreover, this JWT is HS256-signed with UUID 
> key.
> *But, both primary key and UUID are not shared in NiFi 

[jira] [Commented] (NIFI-7771) Infinite loop on WebUI when node stopped in cluster

2020-11-12 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230506#comment-17230506
 ] 

humpfhumpf commented on NIFI-7771:
--

Thx for your reply. My PR could be considered as a workaround.

[~mtien]: if you cannot reproduce the case, do not hesitate to contact me.

> Infinite loop on WebUI when node stopped in cluster
> ---
>
> Key: NIFI-7771
> URL: https://issues.apache.org/jira/browse/NIFI-7771
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.10.0, 1.9.2, 1.12.0, 1.11.4
> Environment: Linux
>Reporter: humpfhumpf
>Priority: Critical
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h2. Context
> Before the bug occurs, one needs:
>  * a load-balancer which uses client IP affinity to “select” one NiFi 
> instance in the cluster;
>  * a fresh and successful OpenID Connect authentication on WebUI.
> Then, stops the NiFi instance, which was “selected” by the load-balancer for 
> you.
> In the mean time, the WebUI (javascript) continues to poll WebAPI by fetching 
> status URLs, but all calls return HTTP 401 error. Then WebUI shows an error 
> screen: “Unauthorized. Unable to validate the access token.”, with 2 links: 
> “log out” and “home”.
> If you click on the “home” link, *the browser enters in an infinite loop of 
> redirects between NiFi and OIDC Identity Provider.*
> The offending HTTP flows is:
>  * “home” link calls: GET /nifi
>  * Redirects to: GET /nifi/
>  ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
>  * Redirects to: GET /nifi/login
>  * Redirects to: GET /openid-connect/auth
>  * Redirects to: GET /nifi-api/access/oidc/callback
>  * Redirects to: GET /nifi
>  * Redirects to: GET /nifi/
>  ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
>  * [loop]
>  
> The stack trace of {{/nifi-api/flow/current-user}} call is:
>  
> {code:java}
> ERROR [NiFi Web Server-284] o.a.nifi.web.security.jwt.JwtService There was an 
> error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the 
> access token.
>      at 
> org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:106)
>      at 
> org.apache.nifi.web.security.jwt.JwtService.getAuthenticationFromToken(JwtService.java:60)
>      at 
> org.apache.nifi.web.security.jwt.JwtAuthenticationProvider.authenticate(JwtAuthenticationProvider.java:48)
>      at 
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:78)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
>      at 
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:99)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
>      ...
> Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match 
> locally computed signature. JWT validity cannot be asserted and should not be 
> trusted.
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:342)
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
>      at 
> org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:102)
>      ...
> {code}
>  
>  
> In my opinion, there are 2 problems:
> h2. Problem 1
> The NiFi JWT token is used (and not replaced) by nfCanvas.init() even after 
> loadCurrentUser() failed with an authentication error (when GET 
> /nifi-api/flow/current-user returns 401).
> In such case, this token, stored in nfStorage (in Javascript Local Storage of 
> browser), should be cleared before redirecting to /nifi/login.
> h2. Problem 2
> The NiFi JWT token is not shared among NiFi cluster.
> This token is not the original id_token returned by the OIDC Identity 
> Provider, but a new one, generated by the NiFi instance on which the browser 
> was routed during the OIDC connection flow.
> This token is closely related to some data stored in H2 users database 
> (nifi-user-keys.h2.db).
> Its “KEY” table contains the following data for each user: email, a primary 
> key (auto increment) and a generated UUID.
> The NiFi JWT token contains (among other things) a copy of email and the 
> auto-incremented primary key. Moreover, this JWT is HS256-signed with UUID 
> 

[jira] [Commented] (NIFI-7771) Infinite loop on WebUI when node stopped in cluster

2020-11-10 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229311#comment-17229311
 ] 

humpfhumpf commented on NIFI-7771:
--

[~thenatog], [~mtien]: do you think that PR #4593 
[https://github.com/apache/nifi/pull/4593] will fix this ticket, because it 
changes the way "to convert OIDC Token to a Login AuthN Token instead of a NiFi 
JWT"?

regards.

> Infinite loop on WebUI when node stopped in cluster
> ---
>
> Key: NIFI-7771
> URL: https://issues.apache.org/jira/browse/NIFI-7771
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.10.0, 1.9.2, 1.12.0, 1.11.4
> Environment: Linux
>Reporter: humpfhumpf
>Priority: Critical
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h2. Context
> Before the bug occurs, one needs:
>  * a load-balancer which uses client IP affinity to “select” one NiFi 
> instance in the cluster;
>  * a fresh and successful OpenID Connect authentication on WebUI.
> Then, stops the NiFi instance, which was “selected” by the load-balancer for 
> you.
> In the mean time, the WebUI (javascript) continues to poll WebAPI by fetching 
> status URLs, but all calls return HTTP 401 error. Then WebUI shows an error 
> screen: “Unauthorized. Unable to validate the access token.”, with 2 links: 
> “log out” and “home”.
> If you click on the “home” link, *the browser enters in an infinite loop of 
> redirects between NiFi and OIDC Identity Provider.*
> The offending HTTP flows is:
>  * “home” link calls: GET /nifi
>  * Redirects to: GET /nifi/
>  ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
>  * Redirects to: GET /nifi/login
>  * Redirects to: GET /openid-connect/auth
>  * Redirects to: GET /nifi-api/access/oidc/callback
>  * Redirects to: GET /nifi
>  * Redirects to: GET /nifi/
>  ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
>  * [loop]
>  
> The stack trace of {{/nifi-api/flow/current-user}} call is:
>  
> {code:java}
> ERROR [NiFi Web Server-284] o.a.nifi.web.security.jwt.JwtService There was an 
> error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the 
> access token.
>      at 
> org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:106)
>      at 
> org.apache.nifi.web.security.jwt.JwtService.getAuthenticationFromToken(JwtService.java:60)
>      at 
> org.apache.nifi.web.security.jwt.JwtAuthenticationProvider.authenticate(JwtAuthenticationProvider.java:48)
>      at 
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:78)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
>      at 
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:99)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
>      ...
> Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match 
> locally computed signature. JWT validity cannot be asserted and should not be 
> trusted.
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:342)
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
>      at 
> org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:102)
>      ...
> {code}
>  
>  
> In my opinion, there are 2 problems:
> h2. Problem 1
> The NiFi JWT token is used (and not replaced) by nfCanvas.init() even after 
> loadCurrentUser() failed with an authentication error (when GET 
> /nifi-api/flow/current-user returns 401).
> In such case, this token, stored in nfStorage (in Javascript Local Storage of 
> browser), should be cleared before redirecting to /nifi/login.
> h2. Problem 2
> The NiFi JWT token is not shared among NiFi cluster.
> This token is not the original id_token returned by the OIDC Identity 
> Provider, but a new one, generated by the NiFi instance on which the browser 
> was routed during the OIDC connection flow.
> This token is closely related to some data stored in H2 users database 
> (nifi-user-keys.h2.db).
> Its “KEY” table contains the following data for each user: email, a primary 
> key (auto increment) and a generated UUID.
> The NiFi JWT token contains (among other things) a copy of email and 

[jira] [Updated] (NIFI-7771) Infinite loop on WebUI when node stopped in cluster

2020-09-08 Thread humpfhumpf (Jira)


 [ 
https://issues.apache.org/jira/browse/NIFI-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

humpfhumpf updated NIFI-7771:
-
Description: 
h2. Context

Before the bug occurs, one needs:
 * a load-balancer which uses client IP affinity to “select” one NiFi instance 
in the cluster;
 * a fresh and successful OpenID Connect authentication on WebUI.

Then, stops the NiFi instance, which was “selected” by the load-balancer for 
you.

In the mean time, the WebUI (javascript) continues to poll WebAPI by fetching 
status URLs, but all calls return HTTP 401 error. Then WebUI shows an error 
screen: “Unauthorized. Unable to validate the access token.”, with 2 links: 
“log out” and “home”.

If you click on the “home” link, *the browser enters in an infinite loop of 
redirects between NiFi and OIDC Identity Provider.*

The offending HTTP flows is:
 * “home” link calls: GET /nifi
 * Redirects to: GET /nifi/
 ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
 * Redirects to: GET /nifi/login
 * Redirects to: GET /openid-connect/auth
 * Redirects to: GET /nifi-api/access/oidc/callback
 * Redirects to: GET /nifi
 * Redirects to: GET /nifi/
 ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
 * [loop]

 

The stack trace of {{/nifi-api/flow/current-user}} call is:

 
{code:java}
ERROR [NiFi Web Server-284] o.a.nifi.web.security.jwt.JwtService There was an 
error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the 
access token.
     at 
org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:106)
     at 
org.apache.nifi.web.security.jwt.JwtService.getAuthenticationFromToken(JwtService.java:60)
     at 
org.apache.nifi.web.security.jwt.JwtAuthenticationProvider.authenticate(JwtAuthenticationProvider.java:48)
     at 
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:78)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
     at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:99)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
     ...
Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match 
locally computed signature. JWT validity cannot be asserted and should not be 
trusted.
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:342)
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
     at 
org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:102)
     ...
{code}
 

 

In my opinion, there are 2 problems:
h2. Problem 1

The NiFi JWT token is used (and not replaced) by nfCanvas.init() even after 
loadCurrentUser() failed with an authentication error (when GET 
/nifi-api/flow/current-user returns 401).

In such case, this token, stored in nfStorage (in Javascript Local Storage of 
browser), should be cleared before redirecting to /nifi/login.
h2. Problem 2

The NiFi JWT token is not shared among NiFi cluster.

This token is not the original id_token returned by the OIDC Identity Provider, 
but a new one, generated by the NiFi instance on which the browser was routed 
during the OIDC connection flow.

This token is closely related to some data stored in H2 users database 
(nifi-user-keys.h2.db).

Its “KEY” table contains the following data for each user: email, a primary key 
(auto increment) and a generated UUID.

The NiFi JWT token contains (among other things) a copy of email and the 
auto-incremented primary key. Moreover, this JWT is HS256-signed with UUID key.

*But, both primary key and UUID are not shared in NiFi cluster.*

It seems to be the reason why WebUI must interrupt its polling to WebAPI: 
stored JWT is no more valid on the new “selected” NiFi instance, to which the 
load-balancer routes your browser.

I think there are 3 solutions:
 * Use a shared secret (from a new property in nifi.properties) to sign NiFi 
JWT tokens. The uselessness of the primary key inside the token should be 
checked;
 * Synchronize the H2 users database among NiFi cluster;
 * Replace the NiFi interal JWT token by the official OIDC JWT “id_token” on 
every WebAPI calls.

 

  was:
h2. Context

Before the bug occurs, one needs:
 * a load-balancer which uses client IP affinity to “select” one NiFi instance 
in the cluster;
 * a fresh and successful OpenID Connect authentication on 

[jira] [Updated] (NIFI-7762) Disabled state of Ports is lost when copy-pasted or instanciated from a template

2020-08-31 Thread humpfhumpf (Jira)


 [ 
https://issues.apache.org/jira/browse/NIFI-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

humpfhumpf updated NIFI-7762:
-
Status: Patch Available  (was: Open)

> Disabled state of Ports is lost when copy-pasted or instanciated from a 
> template
> 
>
> Key: NIFI-7762
> URL: https://issues.apache.org/jira/browse/NIFI-7762
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.11.4, 1.12.0, 1.9.2, 1.10.0
> Environment: Linux
>Reporter: humpfhumpf
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> On UI, when you copy-paste a Disabled local (input/output) port, the 
> pasted-one becomes Stopped: its Disabled state is lost.
> The same bug occurs when a template is instantiated, in which a Disabled Port 
> is included. After investigation, the template in flow.xml.gz stores the 
> Disabled state, but the Disabled state is lost on snippet instantiation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (NIFI-7771) Infinite loop on WebUI when node stopped in cluster

2020-08-31 Thread humpfhumpf (Jira)


 [ 
https://issues.apache.org/jira/browse/NIFI-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

humpfhumpf updated NIFI-7771:
-
Status: Patch Available  (was: Open)

> Infinite loop on WebUI when node stopped in cluster
> ---
>
> Key: NIFI-7771
> URL: https://issues.apache.org/jira/browse/NIFI-7771
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.11.4, 1.12.0, 1.9.2, 1.10.0
> Environment: Linux
>Reporter: humpfhumpf
>Priority: Critical
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h2. Context
> Before the bug occurs, one needs:
>  * a load-balancer which uses client IP affinity to “select” one NiFi 
> instance in the cluster;
>  * a fresh and successful OpenID Connect authentication on WebUI.
> Then, stops the NiFi instance, which was “selected” by the load-balancer for 
> you.
> In the mean time, the WebUI (javascript) continues to poll WebAPI by fetching 
> status URLs, but all calls return HTTP 401 error. Then WebUI shows an error 
> screen: “Unauthorized. Unable to validate the access token.”, with 2 links: 
> “log out” and “home”.
> If you click on the “home” link, *the browser enters in an infinite loop of 
> redirects between NiFi and OIDC Identity Provider.*
> The offending HTTP flows is:
>  * “home” link calls: GET /nifi
>  * Redirects to: GET /nifi/
>  ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
>  * Redirects to: GET /nifi/login
>  * Redirects to: GET /openid-connect/auth
>  * Redirects to: GET /nifi-api/access/oidc/callback
>  * Redirects to: GET /nifi
>  * Redirects to: GET /nifi/
>  ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
>  * [loop]
>  
> The stack trace of {{/nifi-api/flow/current-user}} call is:
>  
> {code:java}
> ERROR [NiFi Web Server-284] o.a.nifi.web.security.jwt.JwtService There was an 
> error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the 
> access token.
>      at 
> org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:106)
>      at 
> org.apache.nifi.web.security.jwt.JwtService.getAuthenticationFromToken(JwtService.java:60)
>      at 
> org.apache.nifi.web.security.jwt.JwtAuthenticationProvider.authenticate(JwtAuthenticationProvider.java:48)
>      at 
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:78)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
>      at 
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:99)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
>      ...
> Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match 
> locally computed signature. JWT validity cannot be asserted and should not be 
> trusted.
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:342)
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
>      at 
> org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:102)
>      ...
> {code}
>  
>  
> In my opinion, there are 2 problems:
> h2. Problem 1
> The NiFi JWT token is used (and not replaced) by nfCanvas.init() even after 
> loadCurrentUser() failed with an authentication error (when GET 
> /nifi-api/flow/current-user returns 401).
> In such case, this token, stored in nfStorage (in Javascript Local Storage of 
> browser), should be cleared before redirecting to /nifi/login.
> h2. Problem 2
> The NiFi JWT token is not shared among NiFi cluster.
> This token is not the original id_token returned by the OIDC Identity 
> Provider, but a new one, generated by the NiFi instance on which the browser 
> was routed during the OIDC connection flow.
> This token is closely related to some data stored in H2 users database 
> (nifi-user-keys.h2.db).
> Its “KEY” table contains the following data for each user: email, a primary 
> key (auto increment) and a generated UUID.
> The NiFi JWT token contains (among other things) a copy of email and the 
> auto-incremented primary key. Moreover, this JWT is HS256-signed with UUID 
> key.
> *But, both primary key and UUID are not shared in NiFi cluster.*
> It seems to be the reason why WebUI must interrupt its polling to 

[jira] [Updated] (NIFI-7771) Infinite loop on WebUI when node stopped in cluster

2020-08-27 Thread humpfhumpf (Jira)


 [ 
https://issues.apache.org/jira/browse/NIFI-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

humpfhumpf updated NIFI-7771:
-
Description: 
h2. Context

Before the bug occurs, one needs:
 * a load-balancer which uses client IP affinity to “select” one NiFi instance 
in the cluster;
 * a fresh and successful OpenID Connect authentication on WebUI.

Then, stops the NiFi instance, which was “selected” by the load-balancer for 
you.

In the mean time, the WebUI (javascript) continues to poll WebAPI by fetching 
status URLs, but all calls return HTTP 401 error. Then WebUI shows an error 
screen: “Unauthorized. Unable to validate the access token.”, with 2 links: 
“log out” and “home”.

If you click on the “home” link, *the browser enters in an infinite loop of 
redirects between NiFi and OIDC Identity Provider.*

The offending HTTP flows is:
 * “home” link calls: GET /nifi
 * Redirects to: GET /nifi/
 ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
 * Redirects to: GET /nifi/login
 * Redirects to: GET /openid-connect/auth
 * Redirects to: GET /nifi-api/access/oidc/callback
 * Redirects to: GET /nifi
 * Redirects to: GET /nifi/
 ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
 * [loop]

 

The stack trace of {{/nifi-api/flow/current-user}} call is:

 
{code:java}
ERROR [NiFi Web Server-284] o.a.nifi.web.security.jwt.JwtService There was an 
error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the 
access token.
     at 
org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:106)
     at 
org.apache.nifi.web.security.jwt.JwtService.getAuthenticationFromToken(JwtService.java:60)
     at 
org.apache.nifi.web.security.jwt.JwtAuthenticationProvider.authenticate(JwtAuthenticationProvider.java:48)
     at 
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:78)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
     at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:99)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
     ...
Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match 
locally computed signature. JWT validity cannot be asserted and should not be 
trusted.
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:342)
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
     at 
org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:102)
     ...
{code}
 

 

In my opinion, there are 2 problems:
h2. Problem 1

The NiFi JWT token is used (and not replaced) by nfCanvas.init() even after 
loadCurrentUser() failed with an authentication error (when GET 
/nifi-api/flow/current-user returns 401).

In such case, this token, stored in nfStorage (in Javascript Local Storage of 
browser), should be cleared before redirecting to /nifi/login.
h2. Problem 2

The NiFi JWT token is not shared among NiFi cluster.

This token is not the original id_token returned by the OIDC Identity Provider, 
but a new one, generated by the NiFi instance on which the browser was routed 
during the OIDC connection flow.

This token is closely related to some data stored in H2 users database 
(nifi-user-keys.h2.db).

Its “KEY” table contains the following data for each user: email, a primary key 
(auto increment) and a generated UUID.

The NiFi JWT token contains (among other things) a copy of email and the 
auto-incremented primary key. Moreover, this JWT is HS256-signed with UUID key.

*But, both primary key and UUID are not shared in NiFi cluster.*

It seems to be the reason why WebUI must interrupt its polling to WebAPI: 
stored JWT is no more valid on the new “selected” NiFi instance, to which the 
load-balancer routes your browser.

I think there are 3 solutions:
 * Use a shared secret (from a new property in nifi.properties) to sign NiFi 
JWT tokens. The uselessness of the primary key inside the token should be 
checked;
 * Synchronize the H2 users database among NiFi cluster;
 * Replace the NiFi interal JWT token by the official OIDC JWT “id_token” on 
every WebAPI call.

 

  was:
h2. Context

Before the bug occurs, it needs:
 * One load-balancer which uses client IP affinity to “select” one NiFi 
instance in the cluster;
 * One fresh and successful OpenID Connect authentication on 

[jira] [Updated] (NIFI-7771) Infinite loop on WebUI when node stopped in cluster

2020-08-27 Thread humpfhumpf (Jira)


 [ 
https://issues.apache.org/jira/browse/NIFI-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

humpfhumpf updated NIFI-7771:
-
Description: 
h2. Context

Before the bug occurs, it needs:
 * One load-balancer which uses client IP affinity to “select” one NiFi 
instance in the cluster;
 * One fresh and successful OpenID Connect authentication on WebUI.

Then, stops the NiFi instance, which was “selected” by the load-balancer for 
you.

In the mean time, the WebUI (javascript) continues to poll WebAPI by fetching 
status URLs, but all calls return HTTP 401 error. Then WebUI shows an error 
screen: “Unauthorized. Unable to validate the access token.”, with 2 links: 
“log out” and “home”.

If you click on the “home” link, *the browser enters in an infinite loop of 
redirects between NiFi and OIDC Identity Provider.*

The offending HTTP flows is:
 * “home” link calls: GET /nifi
 * Redirects to: GET /nifi/
 ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
 * Redirects to: GET /nifi/login
 * Redirects to: GET /openid-connect/auth
 * Redirects to: GET /nifi-api/access/oidc/callback
 * Redirects to: GET /nifi
 * Redirects to: GET /nifi/
 ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
 * [loop]

 

The stack trace of {{/nifi-api/flow/current-user}} call is:

 
{code:java}
ERROR [NiFi Web Server-284] o.a.nifi.web.security.jwt.JwtService There was an 
error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the 
access token.
     at 
org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:106)
     at 
org.apache.nifi.web.security.jwt.JwtService.getAuthenticationFromToken(JwtService.java:60)
     at 
org.apache.nifi.web.security.jwt.JwtAuthenticationProvider.authenticate(JwtAuthenticationProvider.java:48)
     at 
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:78)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
     at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:99)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
     ...
Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match 
locally computed signature. JWT validity cannot be asserted and should not be 
trusted.
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:342)
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
     at 
org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:102)
     ...
{code}
 

 

In my opinion, there are 2 problems:
h2. Problem 1

The NiFi JWT token is used (and not replaced) by nfCanvas.init() even after 
loadCurrentUser() failed with an authentication error (when GET 
/nifi-api/flow/current-user returns 401).

In such case, this token, stored in nfStorage (in Javascript Local Storage of 
browser), should be cleared before redirecting to /nifi/login.
h2. Problem 2

The NiFi JWT token is not shared among NiFi cluster.

This token is not the original id_token returned by the OIDC Identity Provider, 
but a new one, generated by the NiFi instance on which the browser was routed 
during the OIDC connection flow.

This token is closely related to some data stored in H2 users database 
(nifi-user-keys.h2.db).

Its “KEY” table contains the following data for each user: email, a primary key 
(auto increment) and a generated UUID.

The NiFi JWT token contains (among other things) a copy of email and the 
auto-incremented primary key. Moreover, this JWT is HS256-signed with UUID key.

*But, both primary key and UUID are not shared in NiFi cluster.*

It seems to be the reason why WebUI must interrupt its polling to WebAPI: 
stored JWT is no more valid on the new “selected” NiFi instance, to which the 
load-balancer routes your browser.

I think there are 3 solutions:
 * Use a shared secret (from a new property in nifi.properties) to sign NiFi 
JWT tokens. The uselessness of the primary key inside the token should be 
checked;
 * Synchronize the H2 users database among NiFi cluster;
 * Replace the NiFi interal JWT token by the official OIDC JWT “id_token” on 
every WebAPI call.

 

  was:
h2. Context

Before the bug occurs, it needs:
 * One load-balancer which uses client IP affinity to “select” one NiFi 
instance in the cluster;
 * One fresh and successful OpenID Connect authentication 

[jira] [Commented] (NIFI-7771) Infinite loop on WebUI when node stopped in cluster

2020-08-27 Thread humpfhumpf (Jira)


[ 
https://issues.apache.org/jira/browse/NIFI-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17185918#comment-17185918
 ] 

humpfhumpf commented on NIFI-7771:
--

Pull Request for Problem 1: [https://github.com/apache/nifi/pull/4496]

> Infinite loop on WebUI when node stopped in cluster
> ---
>
> Key: NIFI-7771
> URL: https://issues.apache.org/jira/browse/NIFI-7771
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.10.0, 1.9.2, 1.12.0, 1.11.4
> Environment: Linux
>Reporter: humpfhumpf
>Priority: Critical
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h2. Context
> Before the bug occurs, it needs:
>  * One load-balancer which uses client IP affinity to “select” one NiFi 
> instance in the cluster;
>  * One fresh and successful OpenID Connect authentication on WebUI.
> Then, stops the NiFi instance, which was “selected” by the load-balancer for 
> you.
> WebUI (javascript) continues to poll WebAPI by fetching status URLs, but all 
> calls return HTTP 401 error. Then WebUI shows an error screen: “Unauthorized. 
> Unable to validate the access token.”, with 2 links: “log out” and “home”.
> If you click on the “home” link, *the browser enters in an infinite loop of 
> redirects between NiFi and OIDC Identity Provider.*
> The offending HTTP flows is:
>  * “home” link calls: GET /nifi
>  * Redirects to: GET /nifi/
>  ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
>  * Redirects to: GET /nifi/login
>  * Redirects to: GET /openid-connect/auth
>  * Redirects to: GET /nifi-api/access/oidc/callback
>  * Redirects to: GET /nifi
>  * Redirects to: GET /nifi/
>  ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
>  * [loop]
>  
> The stack trace of {{/nifi-api/flow/current-user}} call is:
>  
> {code:java}
> ERROR [NiFi Web Server-284] o.a.nifi.web.security.jwt.JwtService There was an 
> error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the 
> access token.
>      at 
> org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:106)
>      at 
> org.apache.nifi.web.security.jwt.JwtService.getAuthenticationFromToken(JwtService.java:60)
>      at 
> org.apache.nifi.web.security.jwt.JwtAuthenticationProvider.authenticate(JwtAuthenticationProvider.java:48)
>      at 
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:78)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
>      at 
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:99)
>      at 
> org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
>      ...
> Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match 
> locally computed signature. JWT validity cannot be asserted and should not be 
> trusted.
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:342)
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
>      at 
> io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
>      at 
> org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:102)
>      ...
> {code}
>  
>  
> In my opinion, there are 2 problems:
> h2. Problem 1
> The NiFi JWT token is used (and not replaced) by nfCanvas.init() even after 
> loadCurrentUser() failed with an authentication error (when GET 
> /nifi-api/flow/current-user returns 401).
> In such case, this token, stored in nfStorage (in Javascript Local Storage of 
> browser), should be cleared before redirecting to /nifi/login.
> h2. Problem 2
> The NiFi JWT token is not shared among NiFi cluster.
> This token is not the original id_token returned by the OIDC Identity 
> Provider, but a new one, generated by the NiFi instance on which the browser 
> was routed during the OIDC connection flow.
> This token is closely related to some data stored in H2 users database 
> (nifi-user-keys.h2.db).
> Its “KEY” table contains the following data for each user: email, a primary 
> key (auto increment) and a generated UUID.
> The NiFi JWT token contains (among other things) a copy of email and the 
> auto-incremented primary key. Moreover, this JWT is HS256-signed with UUID 
> key.
> *But, both primary key and UUID are not shared in NiFi cluster.*
> It seems to be 

[jira] [Updated] (NIFI-7771) Infinite loop on WebUI when node stopped in cluster

2020-08-27 Thread humpfhumpf (Jira)


 [ 
https://issues.apache.org/jira/browse/NIFI-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

humpfhumpf updated NIFI-7771:
-
Description: 
h2. Context

Before the bug occurs, it needs:
 * One load-balancer which uses client IP affinity to “select” one NiFi 
instance in the cluster;
 * One fresh and successful OpenID Connect authentication on WebUI.

Then, stops the NiFi instance, which was “selected” by the load-balancer for 
you.

WebUI (javascript) continues to poll WebAPI by fetching status URLs, but all 
calls return HTTP 401 error. Then WebUI shows an error screen: “Unauthorized. 
Unable to validate the access token.”, with 2 links: “log out” and “home”.

If you click on the “home” link, *the browser enters in an infinite loop of 
redirects between NiFi and OIDC Identity Provider.*

The offending HTTP flows is:
 * “home” link calls: GET /nifi
 * Redirects to: GET /nifi/
 ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
 * Redirects to: GET /nifi/login
 * Redirects to: GET /openid-connect/auth
 * Redirects to: GET /nifi-api/access/oidc/callback
 * Redirects to: GET /nifi
 * Redirects to: GET /nifi/
 ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
 * [loop]

 

The stack trace of {{/nifi-api/flow/current-user}} call is:

 
{code:java}
ERROR [NiFi Web Server-284] o.a.nifi.web.security.jwt.JwtService There was an 
error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the 
access token.
     at 
org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:106)
     at 
org.apache.nifi.web.security.jwt.JwtService.getAuthenticationFromToken(JwtService.java:60)
     at 
org.apache.nifi.web.security.jwt.JwtAuthenticationProvider.authenticate(JwtAuthenticationProvider.java:48)
     at 
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:78)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
     at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:99)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
     ...
Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match 
locally computed signature. JWT validity cannot be asserted and should not be 
trusted.
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:342)
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
     at 
org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:102)
     ...
{code}
 

 

In my opinion, there are 2 problems:
h2. Problem 1

The NiFi JWT token is used (and not replaced) by nfCanvas.init() even after 
loadCurrentUser() failed with an authentication error (when GET 
/nifi-api/flow/current-user returns 401).

In such case, this token, stored in nfStorage (in Javascript Local Storage of 
browser), should be cleared before redirecting to /nifi/login.
h2. Problem 2

The NiFi JWT token is not shared among NiFi cluster.

This token is not the original id_token returned by the OIDC Identity Provider, 
but a new one, generated by the NiFi instance on which the browser was routed 
during the OIDC connection flow.

This token is closely related to some data stored in H2 users database 
(nifi-user-keys.h2.db).

Its “KEY” table contains the following data for each user: email, a primary key 
(auto increment) and a generated UUID.

The NiFi JWT token contains (among other things) a copy of email and the 
auto-incremented primary key. Moreover, this JWT is HS256-signed with UUID key.

*But, both primary key and UUID are not shared in NiFi cluster.*

It seems to be the reason why WebUI must interrupt its polling to WebAPI: 
stored JWT is no more valid on the new “selected” NiFi instance, to which the 
load-balancer routes your browser.

I think there are 3 solutions:
 * Use a shared secret (from a new property in nifi.properties) to sign NiFi 
JWT tokens. The uselessness of the primary key inside the token should be 
checked;
 * Synchronize the H2 users database among NiFi cluster;
 * Replace the NiFi interal JWT token by the official OIDC JWT “id_token” on 
every WebAPI call.

 

  was:
h2. Context

Before the bug occurs, it needs:
 * One load-balancer which uses client IP affinity to “select” one NiFi 
instance in the cluster;
 * One fresh and successful OpenID Connect authentication on WebUI.

Then, stops 

[jira] [Created] (NIFI-7771) Infinite loop on WebUI when node stopped in cluster

2020-08-27 Thread humpfhumpf (Jira)
humpfhumpf created NIFI-7771:


 Summary: Infinite loop on WebUI when node stopped in cluster
 Key: NIFI-7771
 URL: https://issues.apache.org/jira/browse/NIFI-7771
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core UI
Affects Versions: 1.11.4, 1.12.0, 1.9.2, 1.10.0
 Environment: Linux
Reporter: humpfhumpf


h2. Context

Before the bug occurs, it needs:
 * One load-balancer which uses client IP affinity to “select” one NiFi 
instance in the cluster;
 * One fresh and successful OpenID Connect authentication on WebUI.

Then, stops the NiFi instance, which was “selected” by the load-balancer for 
you.

WebUI (javascript) continues to poll WebAPI by fetching status URLs, but all 
calls return HTTP 401 error. Then WebUI shows an error screen: “Unauthorized. 
Unable to validate the access token.”, with 2 links: “log out” and “home”.

If you click on the “home” link, *the browser enters in an infinite loop of 
redirects between NiFi and OIDC Identity Provider.*

The offending HTTP flows is:
 * “home” link calls: GET /nifi
 * Redirects to: GET /nifi/
 ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
 * Redirects to: GET /nifi/login
 * Redirects to: GET /openid-connect/auth
 * Redirects to: GET /nifi-api/access/oidc/callback
 * Redirects to: GET /nifi
 * Redirects to: GET /nifi/
 ** asynchronously calls: GET /nifi-api/flow/current-user => failed HTTP 401
 * [loop]

 

The stack trace of {{/nifi-api/flow/current-user}} call is:

 
{code:java}
ERROR [NiFi Web Server-284] o.a.nifi.web.security.jwt.JwtService There was an 
error validating the JWT io.jsonwebtoken.JwtException: Unable to validate the 
access token.
     at 
org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:106)
     at 
org.apache.nifi.web.security.jwt.JwtService.getAuthenticationFromToken(JwtService.java:60)
     at 
org.apache.nifi.web.security.jwt.JwtAuthenticationProvider.authenticate(JwtAuthenticationProvider.java:48)
     at 
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:78)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
     at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:99)
     at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
     ...
Caused by: io.jsonwebtoken.SignatureException: JWT signature does not match 
locally computed signature. JWT validity cannot be asserted and should not be 
trusted.
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:342)
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
     at 
io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
     at 
org.apache.nifi.web.security.jwt.JwtService.parseTokenFromBase64EncodedString(JwtService.java:102)
     ...
{code}
 

 

In my opinion, there are 2 problems:
h2. Problem 1

The NiFi JWT token is used (and not replaced) by nfCanvas.init() even after 
loadCurrentUser() failed with an authentication error (when GET 
/nifi-api/flow/current-user returns 401).

In such case, this token, stored in nfStorage (in Javascript Local Storage of 
browser), should be cleared before redirecting to /nifi/login.
h2. Problem 2

The NiFi JWT token is not shared among NiFi cluster.

This token is not the original id_token returned by the OIDC Identity Provider, 
but a new one, generated by the NiFi instance on which your browser was routed 
during the OIDC connection flow.

This token is closely related to some data stored in H2 users database 
(nifi-user-keys.h2.db).

Its “KEY” table contains the following data for each user: email, a primary key 
(auto increment) and a generated UUID.

The NiFi JWT token contains (among other things) a copy of email and the 
auto-incremented primary key. Moreover, this JWT is HS256-signed with UUID key.

*But, both primary key and UUID are not shared in NiFi cluster.*

It seems to be the reason why WebUI must interrupt its polling to WebAPI: 
stored JWT is no more valid on the new “selected” NiFi instance, to which the 
load-balancer routes your browser.

I think there are 3 solutions:
 * Use a shared secret (from a new property in nifi.properties) to sign NiFi 
JWT tokens. The uselessness of the primary key inside the token should be 
checked;
 * Synchronize the H2 users database among NiFi cluster;
 * Replace the NiFi interal JWT token by the official OIDC JWT “id_token” on 
every WebAPI 

[jira] [Updated] (NIFI-7762) Disabled state of Ports is lost when copy-pasted or instanciated from a template

2020-08-25 Thread humpfhumpf (Jira)


 [ 
https://issues.apache.org/jira/browse/NIFI-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

humpfhumpf updated NIFI-7762:
-
Labels: pull-request-available  (was: )

> Disabled state of Ports is lost when copy-pasted or instanciated from a 
> template
> 
>
> Key: NIFI-7762
> URL: https://issues.apache.org/jira/browse/NIFI-7762
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.10.0, 1.9.2, 1.12.0, 1.11.4
> Environment: Linux
>Reporter: humpfhumpf
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> On UI, when you copy-paste a Disabled local (input/output) port, the 
> pasted-one becomes Stopped: its Disabled state is lost.
> The same bug occurs when a template is instantiated, in which a Disabled Port 
> is included. After investigation, the template in flow.xml.gz stores the 
> Disabled state, but the Disabled state is lost on snippet instantiation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (NIFI-7762) Disabled state of Ports is lost when copy-pasted or instanciated from a template

2020-08-25 Thread humpfhumpf (Jira)
humpfhumpf created NIFI-7762:


 Summary: Disabled state of Ports is lost when copy-pasted or 
instanciated from a template
 Key: NIFI-7762
 URL: https://issues.apache.org/jira/browse/NIFI-7762
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.11.4, 1.12.0, 1.9.2, 1.10.0
 Environment: Linux
Reporter: humpfhumpf


On UI, when you copy-paste a Disabled local (input/output) port, the pasted-one 
becomes Stopped: its Disabled state is lost.

The same bug occurs when a template is instantiated, in which a Disabled Port 
is included. After investigation, the template in flow.xml.gz stores the 
Disabled state, but the Disabled state is lost on snippet instantiation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)