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

Joseph Witt commented on NIFI-3661:
-----------------------------------

[~jpetro416] The current construct around whether a property is considered 
sensitive or not is based on whether the developer of a given processor decided 
to have that property be considered sensitive at coding time.  Even for custom 
properties the processor developer could support this by setting 
'sensitive(true)' on the property descriptor of dynamically generated 
properties.

It looks like you're asking for an additional option whereby we'd allow the 
user who is interacting through our REST API (and of course for human users 
this means through their browser in the NiFi UI) that they could indicate 
whether a given property value they are entering should be considered 
sensitive.  In this case, regardless of whether the processor developer thought 
the value was sensitive at coding time the user gets to say at runtime what 
they want.  If so, this is really not about custom properties at all but rather 
is about giving the user a way to say "no, look, regardless of whether the 
developer thinks this should be sensitive I want this value I've entered here 
to be treated as sensitive and never shown again on the UI side and encrypted 
server side.".  

Do I have that right?

> Add Checkbox for custom "Sensitive" properies to the "Add Property" UI
> ----------------------------------------------------------------------
>
>                 Key: NIFI-3661
>                 URL: https://issues.apache.org/jira/browse/NIFI-3661
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core UI
>            Reporter: Joseph Petro
>
> I'm not sure why custom properties for processors would be forced to use 
> clear text. We should be able to make any custom field "sensitive" for 
> security reasons. It's a huge problem when using custom scripts that require 
> sensitive info being passed in (groovy) for example.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to