Hi @Kristopher,
thank you for your comprehensive answer!
As I’m only retrieving SecureStrings a couple of times, I made changes to all the instances and put a separate sequence and invoke of GetAppCredentials.xaml with each activity using a credential and limiting the scope of the variable to that small sequence. While it is/was a small inconvenience, the SecureString usage now feels more structured and standardized.
However, the Workflow Analyzer still raises flags about potential SecureString misusages. Specifically about the variable/argument Password. I assume this is referring to the value in the Password property:
System.Net.NetworkCredential(string.Empty, MySecureString).Password
I am attaching a screenshot and also linking the (incomplete) history of SecureString usage best practices in plain string credential property fields: 'Send SMTP Mail Message' Password - SecureString
Now, am I missing something? Is this password variable accessible somewhere else? Why am I still getting the SecureString Misusage flag? Is there a better workaround to deal with plain string credential property fields? What about that idea of making credential property fields require a SecureString?
Thank you again for your time and expertise.
Cheers
