lordgamez commented on code in PR #1806:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1806#discussion_r1673829258
##########
libminifi/include/core/ParameterTokenParser.h:
##########
@@ -131,5 +138,27 @@ class ParameterTokenParser {
std::vector<std::unique_ptr<ParameterToken>> tokens_;
};
+class NonSensitiveParameterTokenParser : public ParameterTokenParser {
+ public:
+ using ParameterTokenParser::ParameterTokenParser;
+
+ protected:
+ std::string getRawParameterValue(const Parameter& parameter) const override;
+};
+
+class SensitiveParameterTokenParser : public ParameterTokenParser {
+ public:
+ SensitiveParameterTokenParser(std::string input,
utils::crypto::EncryptionProvider& sensitive_values_encryptor)
+ : ParameterTokenParser(std::move(input)),
+ sensitive_values_encryptor_(sensitive_values_encryptor) {
+ }
+
+ protected:
+ std::string getRawParameterValue(const Parameter& parameter) const override;
+
+ private:
+ utils::crypto::EncryptionProvider& sensitive_values_encryptor_;
+};
+
Review Comment:
I think this is a cleaner solution for the following reasons:
- We need information about the sensitivity of the handled property using
parameters to see if its sensitivity and the sensitivity of the parameters
match up which also needs to be passed down. That's multiple conditions, use
cases to check (due to different exception messages) which is abstracted and
handled by the polymorphism so it's easier to read.
- The EncryptionProvider is only needed for sensitive properties, so in case
we are handling non-sensitive properties it's unnecessary to create an
EncryptionProvider to pass to the token parser if we already know it will be
unused.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
