[
https://issues.apache.org/jira/browse/NIFI-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15133422#comment-15133422
]
ASF subversion and git services commented on NIFI-1121:
-------------------------------------------------------
Commit 498b5023ce4f99e67184f399de740b142fca510d in nifi's branch
refs/heads/master from [~alopresto]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=498b502 ]
NIFI-1257 NIFI-1259
Added utility method to return the maximum acceptable password length for PBE
ciphers on JVM with limited strength crypto because BC implementation is
undocumented (based on empirical evidence).
Updated EncryptionMethod definitions to accurately reflect need for unlimited
strength crypto according to algorithm key length.
Added processor logic to invoke keyed cipher.
Added EncryptContent processor property for raw hex key (always visible until
NIFI-1121).
Added validations for KDF (keyed and PBE) and hex key.
Added utility method to return list of valid key lengths for algorithm.
Added description to allowable values for KDF and encryption method in
EncryptContent processor.
Added IV read/write to KeyedCipherProvider and changed from interface to
abstract class.
Added salt read/write logic to NifiLegacy and OpenSSL cipher providers.
Changed RandomIVPBECipherProvider from interface to abstract class.
Updated strong KDF implementations.
Renamed CipherFactory to CipherProviderFactory.
Added unit test for registered KDF resolution from factory.
Updated default iteration count for PBKDF2 cipher provider.
Implemented Scrypt cipher provider.
Added salt translator from mcrypt format to Java format.
Added unit tests for salt formatting and validation.
Added surefire block to groovy unit test profile to enforce 3072 MB heap for
Scrypt test.
Added local Java implementation of Scrypt KDF (and underlying PBKDF2 KDF) from
Will Glozer.
Defined interface for KeyedCipherProvider.
Implemented AES implementation for KeyedCipherProvider.
Added Ruby script to test/resources for external compatibility check.
Added key length check to PBKDF2 cipher provider.
Changed default PRF to SHA-512.
Added salt and key length check to PBKDF2 cipher provider.
Added utility method to check key length validity for cipher families.
Added Bcrypt implementation.
Implemented PBKDF2 cipher provider.
Added default constructor with strong choices for PBKDF2 cipher provider.
Implemented NiFiLegacyCipherProvider and added unit tests.
Added key length parameter to PBKDF2 cipher provider.
Added PRF resolution to PBKDF2 cipher provider.
Added RandomIVPBECipherProvider to allow for non-deterministic IVs.
Added new keyed encryption methods and added boolean field for compatibility
with new KDFs.
Added CipherFactory.
Improved Javadoc in NiFi legacy cipher provider and OpenSSL cipher provider.
Added KeyedCipherProvider interface.
Added OpenSSL PKCS#5 v1.5 EVP_BytesToKey cipher provider and unit test.
This closes #201.
Signed-off-by: Aldrin Piri <[email protected]>
> Allow components' properties to depend on one another
> -----------------------------------------------------
>
> Key: NIFI-1121
> URL: https://issues.apache.org/jira/browse/NIFI-1121
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Mark Payne
>
> Concept: A Processor developer (or Controller Service or Reporting Task
> developer) should be able to indicate when building a PropertyDescriptor that
> the property is "dependent on" another Property. If Property A depends on
> Property B, then the following should happen:
> Property A should not be shown in the Configure dialog unless a value is
> selected for Property B. Additionally, if Property A is dependent on
> particular values of Property B, then Property A should be shown only if
> Property B is set to one of those values.
> For example, in Compress Content, the "Compression Level" property should be
> dependent on the "Mode" property being set to "Compress." This means that if
> the "Mode" property is set to Decompress, then the UI would not show the
> Compression Level property. This will be far less confusing for users, as it
> will allow the UI to hide properties that irrelevant based on the
> configuration.
> Additionally, if Property A depends on Property B and Property A is required,
> then a valid value must be set for Property A ONLY if Property B is set to a
> value that Property A depends on. I.e., in the example above, the Compression
> Level property can be required, but if the Mode is not set to Compress, then
> it doesn't matter if the Compression Level property is set to a valid value -
> the Processor will still be valid, because Compression Level is not a
> relevant property in this case.
> This provides developers to provide validation much more easily, as many
> times the developer currently must implement the customValidate method to
> ensure that if Property A is set that Property B must also be set. In this
> case, it is taken care of by the framework simply by adding a dependency.
> From an API perspective, it would manifest itself as having a new "dependsOn"
> method added to the PropertyDescriptor.Builder class:
> {code}
> /**
> * Indicates that this Property is relevant if and only if the parent property
> has some (any) value set.
> **/
> Builder dependsOn(PropertyDescriptor parent);
> {code}
> {code}
> /**
> * Indicates that this Property is relevant if and only if the parent
> property is set to one of the values included in the 'relevantValues'
> Collection.
> **/
> Builder dependsOn(PropertyDescriptor parent, Collection<AllowableValue>
> relevantValues);
> {code}
> In providing this capability, we will not only be able to hide properties
> that are not valid based on the Processor's other configuration but will also
> make the notion of "Strategy Properties" far more powerful/easy to use. This
> is because we can now have a Property such as "My Capability Strategy" and
> then have properties that are shown for each of the allowed strategies.
> For example, in MergeContent, the Header, Footer, Demarcator could become
> dependent on the "Bin-Packing Algorithm" Merge Strategy. These properties can
> then be thought of logically as properties of that strategy itself.
> This will require a few different parts of the application to be updated:
> * nifi-api - must be updated to support the new methods.
> * nifi-framework-core - must be updated to handle new validation logic for
> components
> * nifi-web - must be updated to show/hide properties based on other
> properties' values
> * nifi-mock - needs to handle the validation logic and ensure that developers
> are using the API properly, throwing AssertionErrors if not
> * nifi-docs - need to update the Developer Guide to explain how this works
> * processors - many processors can be updated to take advantage of this new
> capability
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
