Julien Ledoux created NIFI-13653:
------------------------------------
Summary: Sensitive properties become unsensitive in InvokeHttp
after any property modification
Key: NIFI-13653
URL: https://issues.apache.org/jira/browse/NIFI-13653
Project: Apache NiFi
Issue Type: Bug
Affects Versions: 2.0.0-M4
Environment: Official Docker Image 2.0.0-M4 running on Ubuntu 22.04.4
LTS and Docker v27.0.3
Reporter: Julien Ledoux
Attachments: Screenshot from 2024-08-12 15-28-49.png, Screenshot from
2024-08-12 15-29-31.png, Screenshot from 2024-08-12 15-30-24.png, Screenshot
from 2024-08-12 15-30-46.png, Screenshot from 2024-08-12 15-31-24.png,
Screenshot from 2024-08-12 15-38-37.png
When using the InvokeHttp processor, setting a custom property (which
translates into a request header) with a sensitive value derived from a
sensitive variable in a local Parameter Context initially works as expected.
However, if you later modify an existing property or add a new one under the
"Properties" tab, the previously set sensitive value is incorrectly marked as
unsensitive. This causes the sensitive value to be exposed and the processor
configuration to become invalid. It's important to note that changes made in
other tabs do not trigger this issue; the problem is specific to modifications
within the "Properties" tab.
Here are some screenhots to help reproduce this behavior:
1. Create an InvokeHttp processor and add a custom header with a sensitive
value taken from a Parameter Context
!Screenshot from 2024-08-12 15-28-49.png|width=520,height=342!
!Screenshot from 2024-08-12 15-29-31.png|width=520,height=342!
!Screenshot from 2024-08-12 15-38-37.png|width=520,height=142!
2. Everything is fine so far:
!Screenshot from 2024-08-12 15-31-24.png!
3. After modifying or adding a property, processor bescomes invalid:
!Screenshot from 2024-08-12 15-30-24.png!
4. If you edit again the processor, you'll see that the sensitive value is not
sensitive anymore:
!Screenshot from 2024-08-12 15-30-46.png|width=519,height=344!
I'm working exclusively with the latest 2.0.0-M4 version, so I can't confirm if
this issue affects other versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
