Re: OIDC Redirect loop
I have a very similar configuration and similar problem. After
authenticating with the OIDC server (Keycloak), I often get multiple
failures in verifying the JWT from the nifi servers and have to reload the
browser multiple times until it eventually hits the right one.
On Mon, Apr 27, 2020 at 2:25 PM Andy LoPresto wrote:
> Can you verify the initial redirect to OIDC and the callback are going to
> the same node in NiFi? I see your LB configs are set to sticky sessions,
> but it may be that if the callback is originating from the OIDC IDP server
> rather than the actual client IP, the session affinity is not being
> applied. Regardless, the error appears to indicate that the JWT provided in
> the request to NiFi isn’t able to be validated, which indicates that the
> key used to sign it isn’t present on that node, which is likely due to the
> request being sent to a node other than the one that signed it.
>
> Quick and easy way to validate this would be to change the stateful set #
> to 1 node and attempt the same sequence of operations.
>
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> He/Him
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> On Apr 27, 2020, at 8:12 AM, Ami Goldenberg wrote:
>
> Hi Nathan,
> Indeed, that's the case
>
> On Mon, Apr 27, 2020 at 5:57 PM Nathan Gough wrote:
>
>> Hi Ami,
>>
>> Just to confirm, the OAuth Client ID redirect URL in OIDC is set to "
>> https://${nifi.hostname}:${nifi.port}/nifi-api/access/oidc/callback; and
>> the NiFi property is set "nifi.security.user.oidc.discovery.url=
>> https://accounts.google.com/.well-known/openid-configuration;.
>>
>> Nathan
>>
>> On Mon, Apr 27, 2020 at 12:37 AM Ami Goldenberg
>> wrote:
>>
>>> Hi,
>>>
>>> We are trying to deploy NiFi on kubernetes after successfully using it
>>> for a while.
>>> The issue we are having is that every time we enter our nifi URL it will
>>> redirect us to Google and once we sign in we just get redirected again.
>>>
>>> *The error I see on users.log is:*
>>> o.a.n.w.s.NiFiAuthenticationFilter Attempting request for ()
>>> GET https://XXX.XXX./nifi-api/flow/current-user
>>> (source ip:
>>> 172.32.34.99)
>>> 2020-04-25T19:48:06.256605759Z 2020-04-25 19:48:05,983 ERROR [NiFi
>>> Web Server-16] o.a.nifi.web.security.jwt.JwtService There was an error
>>> validating the JWT
>>> 2020-04-25T19:48:06.256610178Z 2020-04-25 19:48:05,983 ERROR [NiFi Web
>>> Server-16] o.a.nifi.web.security.jwt.JwtService Unable to validate
>>> the access token.
>>> 2020-04-25T19:48:06.256613727Z Caused by: JWT signature does not
>>> match locally computed signature. JWT validity cannot be asserted and
>>> should not be trusted.
>>> 2020-04-25T19:48:06.256617124Z 2020-04-25 19:48:05,984 WARN [NiFi Web
>>> Server-16] o.a.n.w.s.NiFiAuthenticationFilter Rejecting access to web
>>> api:Unable to validate the access token.
>>>
>>> *We're trying to follow practices from blogs and pvillard's repo:*
>>>
>>>-
>>>
>>> https://github.com/pvillard31/nifi-gcp-terraform/tree/master/gcp-cluster-secured-nifi-oidc
>>>-
>>>https://bryanbende.com/development/2017/10/03/apache-nifi-openid-connect
>>>-
>>>https://medium.com/swlh/operationalising-nifi-on-kubernetes-1a8e0ae16a6c
>>>
>>> *Our set up is as such:*
>>>
>>>- OIDC provider is Google
>>>- TLS-toolkit running in server mode inside k8s
>>>- StatefulSet of 3 replicas
>>>- Zookeeper in K8s
>>>- Ingress that is set up to create a load balancer in AWS - with
>>>sticky sessions (based on cookie)
>>>- Service that is set up with sessionAffinity: ClientIP
>>>
>>>
>>> Any idea which direction I should be checking next?anks!
>>>
>>
>
Re: Not Seeing Provenance data
Yes, each node has its persistent stores for each of those directories. On Sat, Apr 11, 2020 at 10:20 AM Patrick Timmins wrote: > Is the underlying storage for the four repositories (provenance, > database, flowfile, and content) consistent within a node? > > Are all three nodes in the cluster using the same type of underlying > storage/device for the various NiFi repositories? > > > On 4/11/2020 8:45 AM, Wyllys Ingersoll wrote: > > Nope, already checked that. > > On Fri, Apr 10, 2020 at 8:23 PM Patrick Timmins wrote: > >> No issues here. Sounds like a timezone / system clock / clock drift >> issue (in a cluster). >> On 4/10/2020 11:59 AM, Joe Witt wrote: >> >> The provenance repo is in large scale use by many many users so >> fundamentally it does work. There are conditions that apparently need >> improving. In the past couple days these items have been flagged by folks >> on this list, JIRAs and PRs raised and merged, all good. If you can help by >> creating a build of the latest and confirm it fixes your case then please >> do so. >> >> Thanks >> >> On Fri, Apr 10, 2020 at 12:48 PM Darren Govoni >> wrote: >> >>> It would seem the feature is either broken completely or only works in >>> specific conditions. >>> >>> Can the Nifi team put a fix on their road map for this? >>> Its a rather central feature to Nifi. >>> >>> Sent from my Verizon, Samsung Galaxy smartphone >>> >>> -- >>> *From:* Wyllys Ingersoll >>> *Sent:* Friday, April 10, 2020 11:17:42 AM >>> *To:* users@nifi.apache.org >>> *Subject:* Re: Not Seeing Provenance data >>> >>> I have a similar problem with viewing provenance. I have a 3-node >>> cluster in a kubernetes environment, the provenance_repository directory >>> for each node is on a persistent data store so it is not deleted or lost >>> between container restarts (which are not very common). My >>> nifi.provenance.repository.max.storage.time is 24 hours. >>> >>> Whenever I try to view any provenance, nothing is ever shown. If I >>> manually inspect the provenance_repository directory, there is a lucene >>> index and TOC being created. >>> >>> I see log messages like these: >>> >>> Submitting query +processorId:882133fe-b684-148b-ad88-7850437ca591 with >>> identifier 64a703fe-0171-1000--65abd91a against index directories >>> [./provenance_repository/lucene-8-index-1560864819888] >>> Returning the following list of index locations because they were >>> finished being written to before 1586531601311: [] >>> Found no events in the Provenance Repository. In order to perform >>> maintenace of the indices, will assume that the first event time is now >>> (1586531601311) >>> >>> >>> Any suggestions? >>> >>> -Wyllys Ingersoll >>> >>> >>> >>> On Thu, Apr 9, 2020 at 11:25 AM Dobbernack, Harald (Key-Work) < >>> harald.dobbern...@key-work.de> wrote: >>> >>> Hey Mark, >>> >>> >>> >>> great news and thank you very much! >>> >>> >>> >>> Happy Holidays! >>> >>> Harald >>> >>> >>> >>> *Von:* Mark Payne >>> *Gesendet:* Donnerstag, 9. April 2020 17:18 >>> *An:* users@nifi.apache.org >>> *Betreff:* Re: Not Seeing Provenance data >>> >>> >>> >>> Thanks Harald, >>> >>> >>> >>> I have created a Jira [1] for this. There’s currently a PR up for it as >>> well. >>> >>> >>> >>> Thanks >>> >>> -Mark >>> >>> >>> >>> [1] https://issues.apache.org/jira/browse/NIFI-7346 >>> >>> >>> >>> On Apr 9, 2020, at 11:14 AM, Dobbernack, Harald (Key-Work) < >>> harald.dobbern...@key-work.de> wrote: >>> >>> >>> >>> Hi Mark, >>> >>> >>> >>> I can confirm after testing that if no provenance event has been >>> generated in a time greater than the set >>> nifi.provenance.repository.max.storage.time >>> then as expected the last recorded provenance events don’t exist anymore >>> but also from then on any new provenance events are also not searchable, >>> the provenance Search remains completely empty regardless of how many flows >>> are active. A
Re: Not Seeing Provenance data
Nope, already checked that. On Fri, Apr 10, 2020 at 8:23 PM Patrick Timmins wrote: > No issues here. Sounds like a timezone / system clock / clock drift issue > (in a cluster). > On 4/10/2020 11:59 AM, Joe Witt wrote: > > The provenance repo is in large scale use by many many users so > fundamentally it does work. There are conditions that apparently need > improving. In the past couple days these items have been flagged by folks > on this list, JIRAs and PRs raised and merged, all good. If you can help by > creating a build of the latest and confirm it fixes your case then please > do so. > > Thanks > > On Fri, Apr 10, 2020 at 12:48 PM Darren Govoni > wrote: > >> It would seem the feature is either broken completely or only works in >> specific conditions. >> >> Can the Nifi team put a fix on their road map for this? >> Its a rather central feature to Nifi. >> >> Sent from my Verizon, Samsung Galaxy smartphone >> >> -- >> *From:* Wyllys Ingersoll >> *Sent:* Friday, April 10, 2020 11:17:42 AM >> *To:* users@nifi.apache.org >> *Subject:* Re: Not Seeing Provenance data >> >> I have a similar problem with viewing provenance. I have a 3-node >> cluster in a kubernetes environment, the provenance_repository directory >> for each node is on a persistent data store so it is not deleted or lost >> between container restarts (which are not very common). My >> nifi.provenance.repository.max.storage.time is 24 hours. >> >> Whenever I try to view any provenance, nothing is ever shown. If I >> manually inspect the provenance_repository directory, there is a lucene >> index and TOC being created. >> >> I see log messages like these: >> >> Submitting query +processorId:882133fe-b684-148b-ad88-7850437ca591 with >> identifier 64a703fe-0171-1000--65abd91a against index directories >> [./provenance_repository/lucene-8-index-1560864819888] >> Returning the following list of index locations because they were >> finished being written to before 1586531601311: [] >> Found no events in the Provenance Repository. In order to perform >> maintenace of the indices, will assume that the first event time is now >> (1586531601311) >> >> >> Any suggestions? >> >> -Wyllys Ingersoll >> >> >> >> On Thu, Apr 9, 2020 at 11:25 AM Dobbernack, Harald (Key-Work) < >> harald.dobbern...@key-work.de> wrote: >> >> Hey Mark, >> >> >> >> great news and thank you very much! >> >> >> >> Happy Holidays! >> >> Harald >> >> >> >> *Von:* Mark Payne >> *Gesendet:* Donnerstag, 9. April 2020 17:18 >> *An:* users@nifi.apache.org >> *Betreff:* Re: Not Seeing Provenance data >> >> >> >> Thanks Harald, >> >> >> >> I have created a Jira [1] for this. There’s currently a PR up for it as >> well. >> >> >> >> Thanks >> >> -Mark >> >> >> >> [1] https://issues.apache.org/jira/browse/NIFI-7346 >> >> >> >> On Apr 9, 2020, at 11:14 AM, Dobbernack, Harald (Key-Work) < >> harald.dobbern...@key-work.de> wrote: >> >> >> >> Hi Mark, >> >> >> >> I can confirm after testing that if no provenance event has been >> generated in a time greater than the set >> nifi.provenance.repository.max.storage.time >> then as expected the last recorded provenance events don’t exist anymore >> but also from then on any new provenance events are also not searchable, >> the provenance Search remains completely empty regardless of how many flows >> are active. As described also *.prov file is then missing in provenance >> repository. After restart of Nifi new prov File will be generated and >> provenance will work again, but only showing stuff generated since last >> NiFi Start. >> >> >> >> So yes, I’d say your Idea >> >> ‘If so, then I think that would understand why it deleted the data. >> It’s trying to age off old data >> >> but unfortunately it doesn’t perform a check to first determine >> whether or not the “old file” >> >> that it’s about to delete is also the “active file”.’ >> >> fits very nicely to my test. >> >> >> >> As a workaround we’re going to set a greater >> nifi.provenance.repository.max.storage.time >> until this can be resolved. >> >> >> >> Thanks again for looking into this. >> >>
Re: Not Seeing Provenance data
I have a similar problem with viewing provenance. I have a 3-node cluster in a kubernetes environment, the provenance_repository directory for each node is on a persistent data store so it is not deleted or lost between container restarts (which are not very common). My nifi.provenance.repository.max.storage.time is 24 hours. Whenever I try to view any provenance, nothing is ever shown. If I manually inspect the provenance_repository directory, there is a lucene index and TOC being created. I see log messages like these: Submitting query +processorId:882133fe-b684-148b-ad88-7850437ca591 with identifier 64a703fe-0171-1000--65abd91a against index directories [./provenance_repository/lucene-8-index-1560864819888] Returning the following list of index locations because they were finished being written to before 1586531601311: [] Found no events in the Provenance Repository. In order to perform maintenace of the indices, will assume that the first event time is now (1586531601311) Any suggestions? -Wyllys Ingersoll On Thu, Apr 9, 2020 at 11:25 AM Dobbernack, Harald (Key-Work) < harald.dobbern...@key-work.de> wrote: > Hey Mark, > > > > great news and thank you very much! > > > > Happy Holidays! > > Harald > > > > *Von:* Mark Payne > *Gesendet:* Donnerstag, 9. April 2020 17:18 > *An:* users@nifi.apache.org > *Betreff:* Re: Not Seeing Provenance data > > > > Thanks Harald, > > > > I have created a Jira [1] for this. There’s currently a PR up for it as > well. > > > > Thanks > > -Mark > > > > [1] https://issues.apache.org/jira/browse/NIFI-7346 > > > > On Apr 9, 2020, at 11:14 AM, Dobbernack, Harald (Key-Work) < > harald.dobbern...@key-work.de> wrote: > > > > Hi Mark, > > > > I can confirm after testing that if no provenance event has been generated > in a time greater than the set nifi.provenance.repository.max.storage.time > then as expected the last recorded provenance events don’t exist anymore > but also from then on any new provenance events are also not searchable, > the provenance Search remains completely empty regardless of how many flows > are active. As described also *.prov file is then missing in provenance > repository. After restart of Nifi new prov File will be generated and > provenance will work again, but only showing stuff generated since last > NiFi Start. > > > > So yes, I’d say your Idea > > ‘If so, then I think that would understand why it deleted the data. > It’s trying to age off old data > > but unfortunately it doesn’t perform a check to first determine > whether or not the “old file” > > that it’s about to delete is also the “active file”.’ > > fits very nicely to my test. > > > > As a workaround we’re going to set a greater > nifi.provenance.repository.max.storage.time > until this can be resolved. > > > > Thanks again for looking into this. > > Harald > > > > > > *Von:* Dobbernack, Harald (Key-Work) > *Gesendet:* Donnerstag, 9. April 2020 15:22 > *An:* users@nifi.apache.org > *Betreff:* AW: Not Seeing Provenance data > > > > Hi Mark, > > > > thank you for looking into this. > > > > The nifi.provenance.repository.max.storage.time setting might explain why > I haven’t been experiencing the effect so often since changing from the > default to 120 hours a few months ago > > > > But I believe provenance stopped working last time although there was an > ‘active’ flows in wait Processor, expiring every hour, going on to ‘send a > message’ before being rerouted to the same wait processor. I would have > expected this generates provenance entries? As I am not actually 100% sure > if that wait processor was in use when last provenance got lost I will > check with a testing system to see if I can reproduce provenance breakage > when no active flows are around for a time greater > nifi.provenance.repository.max.storage.time and I will get back to you. > > > > Thank you! > > Harald > > > > > > *Von:* Mark Payne > *Gesendet:* Donnerstag, 9. April 2020 14:41 > *An:* users@nifi.apache.org > *Betreff:* Re: Not Seeing Provenance data > > > > Hey Daren, Herald, > > > > Thanks for the note. I have seen this once before but couldn’t figure out > what caused it. Restarting addressed the issue. > > > > I think I may understand the problem, now, though, after looking at it > again. > > > > In nifi.properties, there are a couple of property named > “nifi.provenance.repository.max.storage.time” that defaults to “24 hours" > > Is it possible that you went 24 hours (or whatever value is set for tha
Re: alternate web root directory?
Cool, thanks. I wasn't aware of that project. I'll check it out. On Fri, Mar 20, 2020 at 1:21 PM Chris Sampson wrote: > Keycloak Gatekeeper - https://github.com/keycloak/keycloak-gatekeeper > > Then nginx-proxy to set the required X-ProxiedEntity header. > > > *Chris Sampson* > IT Consultant > *Tel:* 07867 843 675 > chris.samp...@naimuri.com > > > > On Fri, 20 Mar 2020 at 17:15, Wyllys Ingersoll < > wyllys.ingers...@keepertech.com> wrote: > >> >> How are you doing OpenID authentication to nifi-registry? We are using >> Keycloak OpenID auth to nifi itself, but couldn't configure it for >> nifi-registry. Everything I've read says its not currently possible. >> >> >> https://community.cloudera.com/t5/Support-Questions/Nifi-Registry-openid/m-p/290935 >> https://issues.apache.org/jira/browse/NIFIREG-313 >> >> >> >> On Fri, Mar 20, 2020 at 12:09 PM Chris Sampson >> wrote: >> >>> We've got a separate NiFi and NiFi Registry ingresses and OIDC for both >>> (different secure cookies used to differentiate the logins in the user's >>> browser). Users are able to login to both within the same browser session >>> without issue. >>> >>> OIDC AuthN in Registry is achieved using keycloak-gatekeeper in front of >>> the Registry instance with an nginx-proxy in between the two to add the >>> required X-ProxiedEntity header for Registry to be able to identify the >>> user and then apply AuthZ. >>> >>> Connection from NiFi to NiFi Registry doesn't go via the ingress, rather >>> they're direct between "internal" services within the k8s namespace. >>> AuthN/Z for the NiFi instances to Registry is via PKI certificates issued >>> (currently) by NiFi Toolkit (may look to use k8s cert-manager in future >>> instead). >>> >>> You're right that it's frustrating the two products don't use the same >>> AuthN/Z connectors, maybe there's a ticket on the Registry backlog for such >>> an update. The NiFi OIDC connector also doesn't use Refresh Token, which is >>> unfortunate as it means the lifetime of the ID/Account Token has to be >>> extended to prevent the user continually being logged out of the UI (which >>> is less secure than having regular refreshes) - think I've seen something >>> on the NiFi backlog to address that, but no work on it last time I checked. >>> >>> >>> *Chris Sampson* >>> IT Consultant >>> *Tel:* 07867 843 675 >>> chris.samp...@naimuri.com >>> >>> >>> >>> On Fri, 20 Mar 2020 at 15:33, Wyllys Ingersoll < >>> wyllys.ingers...@keepertech.com> wrote: >>> >>>> >>>> Yup, I came up with a similar configuration for my NiFi cluster - fully >>>> secured using OIDC directly from NIFI. The issue I had with the >>>> nifi-registry was that it had to use different authentication (Kerberos vs >>>> OIDC) (aside: why aren't the 2 packages sharing the same authentication >>>> modules and configuration models??) but because they were both behind the >>>> same k8s ingress hostname, whenever one would authenticate (nifi vs >>>> nifi-registry) the browser would overwrite the authorization header so we >>>> could only be logged into one at a time. The solution was to add a DNS >>>> alias so we could still share the same k8s ingress but using different >>>> hostnames so that the browser would keep the authorization headers separate >>>> and we could stay authenticated to both within the same browser. >>>> >>>> Wyllys Ingersoll >>>> >>>> On Fri, Mar 20, 2020 at 10:15 AM Chris Sampson < >>>> chris.samp...@naimuri.com> wrote: >>>> >>>>> We've found a clustered k8s NiFi with OIDC auth works OK once: >>>>> >>>>>- Session Affinity annotations added to the nginx Ingress (change >>>>>cookie name appropriately): >>>>> >>>>> ingress.kubernetes.io/affinity: cookie >>>>>> ingress.kubernetes.io/session-cookie-name: "my-nifi" >>>>>> >>>>> >>>>>- Ingress Service (used by the Ingress to talk to NiFi) is >>>>>configured with: >>>>> >>>>> sessionAffinity: ClientIP >>>>>> >>>>> >>>>> We originally had a separate nginx reverse proxy (configured to the >>>>> NiFi instance root "
Re: alternate web root directory?
How are you doing OpenID authentication to nifi-registry? We are using Keycloak OpenID auth to nifi itself, but couldn't configure it for nifi-registry. Everything I've read says its not currently possible. https://community.cloudera.com/t5/Support-Questions/Nifi-Registry-openid/m-p/290935 https://issues.apache.org/jira/browse/NIFIREG-313 On Fri, Mar 20, 2020 at 12:09 PM Chris Sampson wrote: > We've got a separate NiFi and NiFi Registry ingresses and OIDC for both > (different secure cookies used to differentiate the logins in the user's > browser). Users are able to login to both within the same browser session > without issue. > > OIDC AuthN in Registry is achieved using keycloak-gatekeeper in front of > the Registry instance with an nginx-proxy in between the two to add the > required X-ProxiedEntity header for Registry to be able to identify the > user and then apply AuthZ. > > Connection from NiFi to NiFi Registry doesn't go via the ingress, rather > they're direct between "internal" services within the k8s namespace. > AuthN/Z for the NiFi instances to Registry is via PKI certificates issued > (currently) by NiFi Toolkit (may look to use k8s cert-manager in future > instead). > > You're right that it's frustrating the two products don't use the same > AuthN/Z connectors, maybe there's a ticket on the Registry backlog for such > an update. The NiFi OIDC connector also doesn't use Refresh Token, which is > unfortunate as it means the lifetime of the ID/Account Token has to be > extended to prevent the user continually being logged out of the UI (which > is less secure than having regular refreshes) - think I've seen something > on the NiFi backlog to address that, but no work on it last time I checked. > > > *Chris Sampson* > IT Consultant > *Tel:* 07867 843 675 > chris.samp...@naimuri.com > > > > On Fri, 20 Mar 2020 at 15:33, Wyllys Ingersoll < > wyllys.ingers...@keepertech.com> wrote: > >> >> Yup, I came up with a similar configuration for my NiFi cluster - fully >> secured using OIDC directly from NIFI. The issue I had with the >> nifi-registry was that it had to use different authentication (Kerberos vs >> OIDC) (aside: why aren't the 2 packages sharing the same authentication >> modules and configuration models??) but because they were both behind the >> same k8s ingress hostname, whenever one would authenticate (nifi vs >> nifi-registry) the browser would overwrite the authorization header so we >> could only be logged into one at a time. The solution was to add a DNS >> alias so we could still share the same k8s ingress but using different >> hostnames so that the browser would keep the authorization headers separate >> and we could stay authenticated to both within the same browser. >> >> Wyllys Ingersoll >> >> On Fri, Mar 20, 2020 at 10:15 AM Chris Sampson >> wrote: >> >>> We've found a clustered k8s NiFi with OIDC auth works OK once: >>> >>>- Session Affinity annotations added to the nginx Ingress (change >>>cookie name appropriately): >>> >>> ingress.kubernetes.io/affinity: cookie >>>> ingress.kubernetes.io/session-cookie-name: "my-nifi" >>>> >>> >>>- Ingress Service (used by the Ingress to talk to NiFi) is >>>configured with: >>> >>> sessionAffinity: ClientIP >>>> >>> >>> We originally had a separate nginx reverse proxy (configured to the NiFi >>> instance root "/"), but removed that once we fully configured security in >>> the NiFi cluster instances directly and end-to-end through our >>> ingress/service chain (i.e. all https, OIDC done directly by NiFi). >>> >>> We do still have a reverse proxy in front of our NiFi Registry instance >>> though so it can do OIDC auth for us (as Registry doesn't have that >>> capability baked in) - this, again, is configured to go directly to the >>> Registry webroot "/". Bit different for Registry of course as it's not as >>> complex as NiFi and isn't clustered. >>> >>> >>> *Chris Sampson* >>> IT Consultant >>> *Tel:* 07867 843 675 >>> chris.samp...@naimuri.com >>> >>> >>> >>> On Fri, 20 Mar 2020 at 13:44, Wyllys Ingersoll < >>> wyllys.ingers...@keepertech.com> wrote: >>> >>>> >>>> Yes, it would be easier to configure behind a single root context path, >>>> but since nifi uses hardcoded root paths in the responses, it makes things >>>> very challenging. I managed to get thing
Re: alternate web root directory?
Yup, I came up with a similar configuration for my NiFi cluster - fully secured using OIDC directly from NIFI. The issue I had with the nifi-registry was that it had to use different authentication (Kerberos vs OIDC) (aside: why aren't the 2 packages sharing the same authentication modules and configuration models??) but because they were both behind the same k8s ingress hostname, whenever one would authenticate (nifi vs nifi-registry) the browser would overwrite the authorization header so we could only be logged into one at a time. The solution was to add a DNS alias so we could still share the same k8s ingress but using different hostnames so that the browser would keep the authorization headers separate and we could stay authenticated to both within the same browser. Wyllys Ingersoll On Fri, Mar 20, 2020 at 10:15 AM Chris Sampson wrote: > We've found a clustered k8s NiFi with OIDC auth works OK once: > >- Session Affinity annotations added to the nginx Ingress (change >cookie name appropriately): > > ingress.kubernetes.io/affinity: cookie >> ingress.kubernetes.io/session-cookie-name: "my-nifi" >> > >- Ingress Service (used by the Ingress to talk to NiFi) is configured >with: > > sessionAffinity: ClientIP >> > > We originally had a separate nginx reverse proxy (configured to the NiFi > instance root "/"), but removed that once we fully configured security in > the NiFi cluster instances directly and end-to-end through our > ingress/service chain (i.e. all https, OIDC done directly by NiFi). > > We do still have a reverse proxy in front of our NiFi Registry instance > though so it can do OIDC auth for us (as Registry doesn't have that > capability baked in) - this, again, is configured to go directly to the > Registry webroot "/". Bit different for Registry of course as it's not as > complex as NiFi and isn't clustered. > > > *Chris Sampson* > IT Consultant > *Tel:* 07867 843 675 > chris.samp...@naimuri.com > > > > On Fri, 20 Mar 2020 at 13:44, Wyllys Ingersoll < > wyllys.ingers...@keepertech.com> wrote: > >> >> Yes, it would be easier to configure behind a single root context path, >> but since nifi uses hardcoded root paths in the responses, it makes things >> very challenging. I managed to get things working *mostly* with the >> existing paths and some regular expression based path mapping in the k8s >> ingress (i.e. nginx proxy), but I maintain that things would be MUCH easier >> if NiFi wasn't so dependent on hardcoded path names and could unify things >> behind a single root path. >> >> As I said before, if authentication is not involved, it's not a problem, >> but once authentication and tokens are involved, it becomes more >> challenging. Cookie and session affinity settings in the proxy are helpful >> but in the most common k8s cluster configuration, the cluster of NiFi nodes >> (i.e. stateful set of pods) is behind a single service name so the >> proxy/ingress in front of everything doesn't actually know which one it's >> talking to which make affinity harder to establish and maintain. >> >> >> On Fri, Mar 20, 2020 at 9:31 AM Matt Gilman >> wrote: >> >>> Wyllys, >>> >>> The guidance for the proxy configuration is to map it behind a >>> single path. In order to work with any number of context paths that NiFi >>> supports the proxying needs to be based on the root path. Let me know if >>> I'm misunderstanding something. Unfortunately, I'm not super familiar with >>> nginx ingress in k8s environments but it sounds like that session affinity >>> may not working right. >>> >>> On Wed, Mar 18, 2020 at 5:37 PM Wyllys Ingersoll < >>> wyllys.ingers...@keepertech.com> wrote: >>> >>>> Yeah, I've read all of that and I have a semi-working configuration. >>>> The problem is that when using OpenID tokens (oidc) in a clustered >>>> configuration, the node that requests the authentication is the only one >>>> that can validate it. If a user authenticates to node-1, but then later >>>> node-2 gets a request with the token (because its clustered and the user >>>> has no control over which node handles the request), node-2 cannot verify >>>> the token and rejects it. Even configuring sticky-sessions and cookie >>>> affinity in the nginx ingress proxy don't solve the problem as far as I can >>>> tell. >>>> >>>> I don't even know if having it all behind a single root path would make >>>> a difference for the authentication issue, it just makes se
Re: alternate web root directory?
Yes, it would be easier to configure behind a single root context path, but since nifi uses hardcoded root paths in the responses, it makes things very challenging. I managed to get things working *mostly* with the existing paths and some regular expression based path mapping in the k8s ingress (i.e. nginx proxy), but I maintain that things would be MUCH easier if NiFi wasn't so dependent on hardcoded path names and could unify things behind a single root path. As I said before, if authentication is not involved, it's not a problem, but once authentication and tokens are involved, it becomes more challenging. Cookie and session affinity settings in the proxy are helpful but in the most common k8s cluster configuration, the cluster of NiFi nodes (i.e. stateful set of pods) is behind a single service name so the proxy/ingress in front of everything doesn't actually know which one it's talking to which make affinity harder to establish and maintain. On Fri, Mar 20, 2020 at 9:31 AM Matt Gilman wrote: > Wyllys, > > The guidance for the proxy configuration is to map it behind a > single path. In order to work with any number of context paths that NiFi > supports the proxying needs to be based on the root path. Let me know if > I'm misunderstanding something. Unfortunately, I'm not super familiar with > nginx ingress in k8s environments but it sounds like that session affinity > may not working right. > > On Wed, Mar 18, 2020 at 5:37 PM Wyllys Ingersoll < > wyllys.ingers...@keepertech.com> wrote: > >> Yeah, I've read all of that and I have a semi-working configuration. The >> problem is that when using OpenID tokens (oidc) in a clustered >> configuration, the node that requests the authentication is the only one >> that can validate it. If a user authenticates to node-1, but then later >> node-2 gets a request with the token (because its clustered and the user >> has no control over which node handles the request), node-2 cannot verify >> the token and rejects it. Even configuring sticky-sessions and cookie >> affinity in the nginx ingress proxy don't solve the problem as far as I can >> tell. >> >> I don't even know if having it all behind a single root path would make a >> difference for the authentication issue, it just makes setting up the >> reverse proxy configuration easier since you only need to worry about 1 >> path instead of multiple. >> >> >> >> On Wed, Mar 18, 2020 at 2:46 PM Matt Gilman >> wrote: >> >>> Wyllys, >>> >>> NiFi is comprised of any number of web applications. NiFi offers >>> extension points for custom processor configuration UIs and data type >>> viewers. These UIs can be bundled and discovered at runtime. These docs [1] >>> detail the steps necessary for proxying a NiFi instance. >>> >>> Thanks >>> >>> Matt >>> >>> [1] >>> https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#proxy_configuration >>> >>> On Wed, Mar 18, 2020 at 1:29 PM Wyllys Ingersoll < >>> wyllys.ingers...@keepertech.com> wrote: >>> >>>> >>>> I'm surprised you haven't had lots of requests for this already. As it >>>> stands now, I cannot figure out how to configure a secure cluster behind a >>>> reverse proxy (for example, in a kubernetes environment behind an nginx >>>> ingress) that also incorporates OpenID authentication from an external >>>> service. I was thinking that if the NiFi nodes were able to operate under a >>>> single root path, it might make it easier to reverse proxy all of the >>>> different paths that Nifi uses (/nifi, /nifi-api, for example) behind a >>>> single ingress. I think having multiple ingress paths for the nifi service >>>> makes the reverse proxy configuration very complex when authentication >>>> tokens are involved. Without authentication, it works fine. >>>> >>>> Thanks, >>>> Wyllys Ingersoll >>>> >>>> On Wed, Mar 18, 2020 at 12:56 PM Andy LoPresto >>>> wrote: >>>> >>>>> Hi Wyllys, >>>>> >>>>> As I started reading, I was going to suggest the proxy approach. >>>>> Unfortunately, at this time I am unaware of any way to change the paths >>>>> within NiFi itself - there would be substantial refactoring required to >>>>> make that an option. You can open a feature request Jira for that, or >>>>> perhaps the ability to inject a path prefix, but I expect it to be a high >>>>> level of effort to implement. &
Re: alternate web root directory?
Yeah, I've read all of that and I have a semi-working configuration. The problem is that when using OpenID tokens (oidc) in a clustered configuration, the node that requests the authentication is the only one that can validate it. If a user authenticates to node-1, but then later node-2 gets a request with the token (because its clustered and the user has no control over which node handles the request), node-2 cannot verify the token and rejects it. Even configuring sticky-sessions and cookie affinity in the nginx ingress proxy don't solve the problem as far as I can tell. I don't even know if having it all behind a single root path would make a difference for the authentication issue, it just makes setting up the reverse proxy configuration easier since you only need to worry about 1 path instead of multiple. On Wed, Mar 18, 2020 at 2:46 PM Matt Gilman wrote: > Wyllys, > > NiFi is comprised of any number of web applications. NiFi offers extension > points for custom processor configuration UIs and data type viewers. These > UIs can be bundled and discovered at runtime. These docs [1] detail the > steps necessary for proxying a NiFi instance. > > Thanks > > Matt > > [1] > https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#proxy_configuration > > On Wed, Mar 18, 2020 at 1:29 PM Wyllys Ingersoll < > wyllys.ingers...@keepertech.com> wrote: > >> >> I'm surprised you haven't had lots of requests for this already. As it >> stands now, I cannot figure out how to configure a secure cluster behind a >> reverse proxy (for example, in a kubernetes environment behind an nginx >> ingress) that also incorporates OpenID authentication from an external >> service. I was thinking that if the NiFi nodes were able to operate under a >> single root path, it might make it easier to reverse proxy all of the >> different paths that Nifi uses (/nifi, /nifi-api, for example) behind a >> single ingress. I think having multiple ingress paths for the nifi service >> makes the reverse proxy configuration very complex when authentication >> tokens are involved. Without authentication, it works fine. >> >> Thanks, >> Wyllys Ingersoll >> >> On Wed, Mar 18, 2020 at 12:56 PM Andy LoPresto >> wrote: >> >>> Hi Wyllys, >>> >>> As I started reading, I was going to suggest the proxy approach. >>> Unfortunately, at this time I am unaware of any way to change the paths >>> within NiFi itself - there would be substantial refactoring required to >>> make that an option. You can open a feature request Jira for that, or >>> perhaps the ability to inject a path prefix, but I expect it to be a high >>> level of effort to implement. >>> >>> >>> Andy LoPresto >>> alopre...@apache.org >>> *alopresto.apa...@gmail.com * >>> He/Him >>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >>> >>> On Mar 18, 2020, at 9:25 AM, Wyllys Ingersoll < >>> wyllys.ingers...@keepertech.com> wrote: >>> >>> >>> Is there a way to configure nifi to use a different root directory for >>> web requests? >>> >>> We would like everything to be under a common root such as: >>> /XXX/nifi/... >>> /XXX/nifi-api/... >>> >>> Having to proxy 2 (/nifi and /nifi-api) paths makes it very difficult to >>> setup a reverse proxy that also can incorporate OpenID authentication >>> tokens to a secure backend cluster of nodes. >>> >>> >>> >>> >>>
Re: alternate web root directory?
I'm surprised you haven't had lots of requests for this already. As it stands now, I cannot figure out how to configure a secure cluster behind a reverse proxy (for example, in a kubernetes environment behind an nginx ingress) that also incorporates OpenID authentication from an external service. I was thinking that if the NiFi nodes were able to operate under a single root path, it might make it easier to reverse proxy all of the different paths that Nifi uses (/nifi, /nifi-api, for example) behind a single ingress. I think having multiple ingress paths for the nifi service makes the reverse proxy configuration very complex when authentication tokens are involved. Without authentication, it works fine. Thanks, Wyllys Ingersoll On Wed, Mar 18, 2020 at 12:56 PM Andy LoPresto wrote: > Hi Wyllys, > > As I started reading, I was going to suggest the proxy approach. > Unfortunately, at this time I am unaware of any way to change the paths > within NiFi itself - there would be substantial refactoring required to > make that an option. You can open a feature request Jira for that, or > perhaps the ability to inject a path prefix, but I expect it to be a high > level of effort to implement. > > > Andy LoPresto > alopre...@apache.org > *alopresto.apa...@gmail.com * > He/Him > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Mar 18, 2020, at 9:25 AM, Wyllys Ingersoll < > wyllys.ingers...@keepertech.com> wrote: > > > Is there a way to configure nifi to use a different root directory for web > requests? > > We would like everything to be under a common root such as: > /XXX/nifi/... > /XXX/nifi-api/... > > Having to proxy 2 (/nifi and /nifi-api) paths makes it very difficult to > setup a reverse proxy that also can incorporate OpenID authentication > tokens to a secure backend cluster of nodes. > > > > >
alternate web root directory?
Is there a way to configure nifi to use a different root directory for web requests? We would like everything to be under a common root such as: /XXX/nifi/... /XXX/nifi-api/... Having to proxy 2 (/nifi and /nifi-api) paths makes it very difficult to setup a reverse proxy that also can incorporate OpenID authentication tokens to a secure backend cluster of nodes.
Re: GitFlowPersistenceProvider not pushing upstream
Thanks, that was helpful. I had to enable my nifi-registry user to be an
"owner" in order to be able to push changes to the master branch in
gitlab.
On Fri, Mar 13, 2020 at 1:30 PM Bryan Bende wrote:
> If you turn on debug logging for the package
> "org.apache.nifi.registry.provider.flow.git" then you should see a message
> like this:
>
> logger.debug("Took a push request sent at {} to {}...", offeredTimestamp,
> remoteToPush);
>
> If it fails to push then:
>
> logger.error(format("Failed to push commits to %s due to %s", remoteToPush,
> e), e);
>
>
> On Fri, Mar 13, 2020 at 12:54 PM Wyllys Ingersoll <
> wyllys.ingers...@keepertech.com> wrote:
>
>>
>> Yes, its set to "origin", and origin is defined in the .git/config file
>> to be an upstream repo with HTTPS.
>>
>>
>> On Fri, Mar 13, 2020 at 12:50 PM Bryan Bende wrote:
>>
>>> Did you specify the remote to push to in the configuration of the
>>> provider?
>>>
>>>
>>>
>>> On Fri, Mar 13, 2020 at 12:40 PM Wyllys Ingersoll <
>>> wyllys.ingers...@keepertech.com> wrote:
>>>
>>>>
>>>> Using: NiFi 1.11.3, NiFi-Registry: 1.5.0
>>>>
>>>> I have configured my registry to use the git provider and it is
>>>> initialized and seems to be working fine with my nifi configuration - i.e.
>>>> flow versions are being recorded as expected and things are working as far
>>>> as I can tell.
>>>>
>>>> The problem is that my nifi-registry git configuration has an upstream
>>>> origin to an external git server, but the nifi-registry is not pushing
>>>> changes upstream, so the main gitlab server never sees any changes to the
>>>> nifi registry repository. I see no errors or messages in the nifi-registry
>>>> logs indicating that it is even trying to push.
>>>>
>>>> Is this a known bug? Am I misconfigured?
>>>>
>>>> thanks,
>>>>Wyllys Ingersoll
>>>>
>>>>
>>>>
>>>>
Re: GitFlowPersistenceProvider not pushing upstream
Yes, its set to "origin", and origin is defined in the .git/config file to be an upstream repo with HTTPS. On Fri, Mar 13, 2020 at 12:50 PM Bryan Bende wrote: > Did you specify the remote to push to in the configuration of the provider? > > > > On Fri, Mar 13, 2020 at 12:40 PM Wyllys Ingersoll < > wyllys.ingers...@keepertech.com> wrote: > >> >> Using: NiFi 1.11.3, NiFi-Registry: 1.5.0 >> >> I have configured my registry to use the git provider and it is >> initialized and seems to be working fine with my nifi configuration - i.e. >> flow versions are being recorded as expected and things are working as far >> as I can tell. >> >> The problem is that my nifi-registry git configuration has an upstream >> origin to an external git server, but the nifi-registry is not pushing >> changes upstream, so the main gitlab server never sees any changes to the >> nifi registry repository. I see no errors or messages in the nifi-registry >> logs indicating that it is even trying to push. >> >> Is this a known bug? Am I misconfigured? >> >> thanks, >>Wyllys Ingersoll >> >> >> >>
GitFlowPersistenceProvider not pushing upstream
Using: NiFi 1.11.3, NiFi-Registry: 1.5.0 I have configured my registry to use the git provider and it is initialized and seems to be working fine with my nifi configuration - i.e. flow versions are being recorded as expected and things are working as far as I can tell. The problem is that my nifi-registry git configuration has an upstream origin to an external git server, but the nifi-registry is not pushing changes upstream, so the main gitlab server never sees any changes to the nifi registry repository. I see no errors or messages in the nifi-registry logs indicating that it is even trying to push. Is this a known bug? Am I misconfigured? thanks, Wyllys Ingersoll
Re: NiFi Kubernetes question
We had success running a 3-node cluster in kubernetes using modified configuration scripts from the AlexJones github repo - https://github.com/AlexsJones/nifi Ours is on an internal bare-metal k8s lab configuration, not in a public cloud at this time, but the basics are the same either way. - setup nifi as a stateful set so you can scale up or down as needed. When a pod fails, k8s will spawn another to take its place and zookeeper will manage the election of the master during transitions. - manage your certs as K8S secrets. - you also need to also have a stateful set of zookeeper pods for managing the nifi servers. - use persistent volume mounts to hold the flowfile, database, content, and provenance _repository directories On Mon, Oct 21, 2019 at 11:21 AM Joe Gresock wrote: > Apologies if this has been answered on the list already.. > > Does anyone have knowledge of the latest in the realm of nifi kubernetes > support? I see some pages like https://hub.helm.sh/charts/cetic/nifi, > and https://github.com/AlexsJones/nifi but am unsure which example to > pick to start with. > > I'm curious how well kubernetes maintains the nifi cluster state with pod > failures. I.e., do any of the k8s implementations play well with the nifi > cluster list so that we don't have dangling downed nodes in the cluster? > Also, I'm wondering how certs are managed in a secured cluster. > > Appreciate any nudge in the right direction, > Joe >
Re: HandleHTTPRequest 503 error issue
Yes, thanks. Is there an ETA for 1.10? On Fri, Oct 4, 2019 at 3:05 PM Peter Turcsanyi wrote: > Hi Wyllys, > > It has been fixed in NIFI-6317 > <https://issues.apache.org/jira/browse/NIFI-6317> which will be shipped > in the upcoming 1.10 release. > Could you please retest your workload on that version when it is available? > > Regards, > Peter Turcsanyi > > On Fri, Oct 4, 2019 at 6:28 PM Wyllys Ingersoll < > wyllys.ingers...@keepertech.com> wrote: > >> >> I believe this issue: https://issues.apache.org/jira/browse/NIFI-5522 >> is a regression in Nifi 1.9.2, it was marked as fixed in 1.8.0, but Im >> seeing it a lot in 1.9.2 >> >> I can recreate it fairly regularly when I am hitting the endpoint pretty >> heavily and an error is encountered. The process return 503 error (or >> nothing at all) and cannot be stopped or restarted without rebooting the >> entire node. >> >> -Wyllys Ingersoll >> >>
HandleHTTPRequest 503 error issue
I believe this issue: https://issues.apache.org/jira/browse/NIFI-5522 is a regression in Nifi 1.9.2, it was marked as fixed in 1.8.0, but Im seeing it a lot in 1.9.2 I can recreate it fairly regularly when I am hitting the endpoint pretty heavily and an error is encountered. The process return 503 error (or nothing at all) and cannot be stopped or restarted without rebooting the entire node. -Wyllys Ingersoll
Re: feature suggestion
Understood. Thanks for the help (really) ! On Wed, Jun 19, 2019 at 1:24 PM Andy LoPresto wrote: > Wyllys, > > It may help to think of NiFi processors the same way you think about *nix > command line tools — each tool has a very specific and limited > responsibility and focus. Rather than continue to add generic features to > each in order to cover all use cases, you combine the right tools in the > necessary order to achieve your goal (i.e. cat, grep, sed, cut, etc.). No > individual tool cares where the input data is coming from or where the > output data is going; a critical idea which is part of the Flow Based > Programming [1] design philosophy that NiFi models. Adding features > increases complexity, configuration, and the opportunity for bugs or > unexpected behavior, especially in edge cases. > > The InvokeHTTP processor is concerned with transmitting flowfile > attributes & content to a remote HTTP endpoint. Rather than include > additional functionality to massage the content, we would recommend using > an additional preceding processor to form the content into the expected > format. > > I definitely understand the desire to add “just one thing” to make a > specific use case easier, but we have to balance that with the > maintainability and supportability of the framework as a whole moving > forward. Hope this helps. Thanks. > > [1] > https://nifi.apache.org/docs/nifi-docs/html/overview.html#the-core-concepts-of-nifi > > Andy LoPresto > alopre...@apache.org > *alopresto.apa...@gmail.com * > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Jun 19, 2019, at 7:23 AM, Wyllys Ingersoll < > wyllys.ingers...@keepertech.com> wrote: > > OK, that helps. I put AttributesToJSON and a ReplaceText processor in > front of my invokeHTTP and was able to get it to work as I wanted. > > One of the confusing issues is that InvokeHTTP does not have any > configuration that allows me to modify the flowfile content, which forces > me to use those additional processors to make sure the content is correct. > It might be a little more convenient if invokeHTTP had a couple of > parameters to allow for setting the content format so that the extra > processors are not necessary. > > > > On Tue, Jun 18, 2019 at 11:01 PM Andy LoPresto > wrote: > >> Wyllys, >> >> I am sorry but I am having a different experience when I try to reproduce >> the scenario you describe. >> >> I set up a sample flow which uses an InvokeHTTP processor to send a >> flowfile to a remote HTTP endpoint. That endpoint happens to be a disparate >> flow in NiFi because it was easy to configure on the fly, but it could be >> any remote web server. >> >> I can verify that when I send flowfile content, it is not transmitting >> the flowfile attributes unless I explicitly configure it to. Please see >> below an annotated excerpt from the nifi-app.log file and a link to the >> template I exported with this flow. >> >> I think the issue may be one of terminology? Attributes and content are >> separate in NiFi and flowfiles distinguish very cleanly between the two. >> Are you referring to elements of the JSON body as “attributes”? In that >> case, you would need to use a ReplaceText, EvaluateJsonPath, >> JoltTransformJson, or other processor as Jerry suggested to >> extract/manipulate the JSON in the flowfile content to the exact data you >> wish to send over HTTP before using InvokeHTTP. If you want to do this but >> not lose the other content, you can split the flow by dragging an >> additional “success” relationship from the preceding processor to handle >> the two different flow behaviors. >> >> Template for flow (tested on NiFi 1.9.2): >> https://gist.github.com/alopresto/0be1cf65ba70d5d36aeae1e6f2f60702 >> >> Log output from flow: >> https://gist.github.com/alopresto/b596372005032b9c80063a0652a955ea >> >> >> Andy LoPresto >> alopre...@apache.org >> *alopresto.apa...@gmail.com * >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >> On Jun 18, 2019, at 7:47 PM, Jerry Vinokurov >> wrote: >> >> Hi Wyllys, >> >> One way that I solve this problem in my work is to use the >> AttributesToJSON processor to form the body of the POST before sending it. >> Granted, that does override the body of the flowfile, so I'm not sure if >> that works for your specific case, but it does allow you to select which >> attributes you want to turn into JSON key/value pairs. For more complex >> formations I would suggest checking out the JOLT Transform processor, which >> can b
Re: feature suggestion
OK, that helps. I put AttributesToJSON and a ReplaceText processor in
front of my invokeHTTP and was able to get it to work as I wanted.
One of the confusing issues is that InvokeHTTP does not have any
configuration that allows me to modify the flowfile content, which forces
me to use those additional processors to make sure the content is correct.
It might be a little more convenient if invokeHTTP had a couple of
parameters to allow for setting the content format so that the extra
processors are not necessary.
On Tue, Jun 18, 2019 at 11:01 PM Andy LoPresto wrote:
> Wyllys,
>
> I am sorry but I am having a different experience when I try to reproduce
> the scenario you describe.
>
> I set up a sample flow which uses an InvokeHTTP processor to send a
> flowfile to a remote HTTP endpoint. That endpoint happens to be a disparate
> flow in NiFi because it was easy to configure on the fly, but it could be
> any remote web server.
>
> I can verify that when I send flowfile content, it is not transmitting the
> flowfile attributes unless I explicitly configure it to. Please see below
> an annotated excerpt from the nifi-app.log file and a link to the template
> I exported with this flow.
>
> I think the issue may be one of terminology? Attributes and content are
> separate in NiFi and flowfiles distinguish very cleanly between the two.
> Are you referring to elements of the JSON body as “attributes”? In that
> case, you would need to use a ReplaceText, EvaluateJsonPath,
> JoltTransformJson, or other processor as Jerry suggested to
> extract/manipulate the JSON in the flowfile content to the exact data you
> wish to send over HTTP before using InvokeHTTP. If you want to do this but
> not lose the other content, you can split the flow by dragging an
> additional “success” relationship from the preceding processor to handle
> the two different flow behaviors.
>
> Template for flow (tested on NiFi 1.9.2):
> https://gist.github.com/alopresto/0be1cf65ba70d5d36aeae1e6f2f60702
>
> Log output from flow:
> https://gist.github.com/alopresto/b596372005032b9c80063a0652a955ea
>
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> On Jun 18, 2019, at 7:47 PM, Jerry Vinokurov
> wrote:
>
> Hi Wyllys,
>
> One way that I solve this problem in my work is to use the
> AttributesToJSON processor to form the body of the POST before sending it.
> Granted, that does override the body of the flowfile, so I'm not sure if
> that works for your specific case, but it does allow you to select which
> attributes you want to turn into JSON key/value pairs. For more complex
> formations I would suggest checking out the JOLT Transform processor, which
> can be quite powerful, if somewhat painful to work with.
>
> Jerry
>
> On Tue, Jun 18, 2019 at 9:49 PM Wyllys Ingersoll <
> wyllys.ingers...@keepertech.com> wrote:
>
>> Andy -
>>Yes, Im referring to the PUT and POST methods, in which case the
>> processor just sends the entire flowfile as a JSON object in the message
>> body. I'd prefer to either have the option to exclude some of the flow
>> attributes or (even better) have the ability to craft my own message body.
>> There are lots of instances where the receiver of the PUT or POST expects a
>> particular structure that doesn't easily work with just a flat JSON-ified
>> set of flow attributes.
>>
>> One example:
>> We have a flow that has an authentication token as one of the
>> attributes and a bunch of other key/value pairs used for other purposes.
>> In the InvokeHTTP processor, I use the auth token attribute in an
>> Authorization header by creating a dynamic attribute with the correct
>> format ("Authorization: Bearer ${token}"). However, the recipient of the
>> PUT/POST also expects the body of the request to be formatted a specific
>> way and does not expect or want to see the auth token or some of the other
>> unrelated information that ends up getting transmitted as part of the
>> message body simply because they are flow attributes. So, if InvokeHTTP
>> were able to exclude certain fields from the message body AND also allow
>> the body of the message to be configurable into a structure other than just
>> a flat dictionary of flow attributes, it would be much more powerful and
>> useful. As it stands, I'm thinking I may have to develop a custom
>> processor to get past this issue, which is not ideal at all.
>>
>> Thanks!
>> Wyllys Ingersoll
>>
>>
>>
>>
>> On Tue, Jun 18, 2019 at 8:34 PM Andy LoPresto
>> wrote:
>>
>>> Hi Wyllys,
>
Re: feature suggestion
Andy -
Yes, Im referring to the PUT and POST methods, in which case the
processor just sends the entire flowfile as a JSON object in the message
body. I'd prefer to either have the option to exclude some of the flow
attributes or (even better) have the ability to craft my own message body.
There are lots of instances where the receiver of the PUT or POST expects a
particular structure that doesn't easily work with just a flat JSON-ified
set of flow attributes.
One example:
We have a flow that has an authentication token as one of the attributes
and a bunch of other key/value pairs used for other purposes. In the
InvokeHTTP processor, I use the auth token attribute in an Authorization
header by creating a dynamic attribute with the correct format
("Authorization: Bearer ${token}"). However, the recipient of the PUT/POST
also expects the body of the request to be formatted a specific way and
does not expect or want to see the auth token or some of the other
unrelated information that ends up getting transmitted as part of the
message body simply because they are flow attributes. So, if InvokeHTTP
were able to exclude certain fields from the message body AND also allow
the body of the message to be configurable into a structure other than just
a flat dictionary of flow attributes, it would be much more powerful and
useful. As it stands, I'm thinking I may have to develop a custom
processor to get past this issue, which is not ideal at all.
Thanks!
Wyllys Ingersoll
On Tue, Jun 18, 2019 at 8:34 PM Andy LoPresto wrote:
> Hi Wyllys,
>
> Sorry to hear you are having trouble with this processor. Can you please
> provide a more detailed example of an incoming flowfile and what your
> expected output is compared to what is currently happening? Based on my
> understanding, the flowfile attributes are only sent as request headers,
> and that can be controlled using the regular expression value of
> “Attributes to Send”. I believe only the flowfile content is sent as the
> request body when using PUT or POST. Thanks.
>
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> On Jun 18, 2019, at 3:01 PM, Wyllys Ingersoll <
> wyllys.ingers...@keepertech.com> wrote:
>
>
> it would be nice to be able to exclude attributes from the message body
> when doing a PUT or POST in the invokeHTTP processor. Currently, there's
> no way to selectively choose which attributes go into the message body
> without using a replaceText processor in front of it, but that completely
> removes those attributes from being used later which is not always the
> desirable.
>
> There are lots of situations where it would be nice to be able to use some
> flow attributes just in the request header or for other parts of the
> processor configuration without including them in the message body itself.
> For example, taking an authentication token that is carried along as a flow
> attribute so it can be used in an authorization header and NOT included in
> the body of the request.
>
> In general, invokeHTTP needs to allow for more control over the format and
> content of the message body being sent.
>
> -Wyllys Ingersoll
>
>
>
feature suggestion
it would be nice to be able to exclude attributes from the message body when doing a PUT or POST in the invokeHTTP processor. Currently, there's no way to selectively choose which attributes go into the message body without using a replaceText processor in front of it, but that completely removes those attributes from being used later which is not always the desirable. There are lots of situations where it would be nice to be able to use some flow attributes just in the request header or for other parts of the processor configuration without including them in the message body itself. For example, taking an authentication token that is carried along as a flow attribute so it can be used in an authorization header and NOT included in the body of the request. In general, invokeHTTP needs to allow for more control over the format and content of the message body being sent. -Wyllys Ingersoll
nifi cluster in kubernetes
Im trying to setup a simple 3-node nifi cluster in kubernetes and am having a problem with any configuration beyond 1 node. All of the nodes start up and eventually 1 is elected the primary and the other 2 come up as "Connected" and all 3 appear to be sending and receiving heartbeats correctly. The problem arises whenever I attempt to actually start building a flow and adding processors. The message I get whenever I try to add a processor to an empty flow looks like this: 2019-06-11 21:04:20,948 INFO [Replicate Request Thread-10] o.a.n.c.c.h.r.ThreadPoolRequestReplicator Received a status of 409 from nifi-1:8080 for request POST /nifi-api/process-groups/4856e9fe-016b-1000-cda8-c66890e935db/processors when performing first stage of two-stage commit. The action will not occur. Node explanation: Transaction d5baf8b8-b9fa-4d45-9c62-af1bbe202b6a is already in progress. Details: * Nifi 1.9.2 configured as a StatefulSet (replicas = 3) in kubernetes, exposing containerPorts 8080, 2881, and 2882 to the rest of the cluster * Persistent Volumes used for flowfile, database, provenance, and content repositories * Using external zookeeper in a 3 node cluster (also in Kubernetes) that appears to work correctly and has no errors. * Nginx Ingress (reverse proxy) in front of everything that proxies /nifi and /nifi-app to the internal k8s nifi services in the cluster. - X-ProxyHost and X-ProxyPort are set correctly in the reverse proxy settings relevant nifi cluster parameters for 1 of the nodes: nifi.cluster.is.node=true nifi.cluster.node.address=nifi-0 nifi.cluster.node.protocol.port=2882 nifi.cluster.node.protocol.threads=10 nifi.cluster.node.protocol.max.threads=50 nifi.cluster.node.event.history.size=25 nifi.cluster.node.connection.timeout=10 secs nifi.cluster.node.read.timeout=10 secs nifi.cluster.node.max.concurrent.requests=100 nifi.cluster.firewall.file= nifi.cluster.flow.election.max.wait.time=1 mins nifi.cluster.flow.election.max.candidates= nifi.web.http.host=nifi-0 nifi.web.http.port=8080 nifi.web.http.network.interface.default= nifi.web.https.host= nifi.web.https.port= nifi.web.https.network.interface.default= nifi.web.jetty.working.directory=./work/jetty nifi.web.jetty.threads=200 nifi.web.max.header.size=16 KB nifi.web.proxy.context.path=/nifi,/nifi-api nifi.web.proxy.host= Any help here would be greatly appreciated. thanks, Wyllys Ingersoll
