Currently, the entire value of the "connectString" parameter is stored as a secret to be able to protect any passwords that might be used in the connection string. Since the connection string is stored as a secret, it cannot be read by users after being saved.
Usually, a secret contains a password and nothing else, and so it consists entirely of confidential information. A connection string does not even necessarily contain a password and contains much more additional information, which is not as/even sensitive. In fact, on Windows, a good practice is to configure only a single component for an AVEVA Adapter instance and then run the AVEVA Adapter using a service account that has the minimum privileges needed to the data source. This allows the user to avoid dealing with passwords entirely, especially if the service account is a gMSA. That is, if you are following good security practices on Windows, then you will not need to use passwords in the connection string.
Also, to counter the argument that storing the entire connection string, even if it does not contain a password, as a secret is still a good idea because it is more secure, then why not store the entire configuration of the AVEVA Adapter as a secret? I'm all for security, but I also want to be able to see and edit the configuration easily, which includes the connection string. It would be different if we could see the values of secrets.
One workaround is to store some of the connection information in a DSN and then reference the DSN in the connection string. However, by my understanding, this would also require the "dataProvider" parameter to be "ODBC".
Please store only the confidential part of a connection string as a secret and leave the rest not stored as a secret. I'll leave it to AVEVA to determine a good way to do this, but here are some ideas:
Allow the user to choose whether or not the connection string gets stored as a secret. Disadvantage: if you choose to store the connection string as a secret, then the issues mentioned in this suggestion still apply.
Have 2 parameters: unencryptedConnectString, which is not stored as a secret, and encryptedConnectString, which is stored as a secret. The 2 strings are concatenated to form the full connection string. Disadvantage: the confidential part of the connection string must be at the very beginning or the very end of the connection string, depending on the order in which we want to concatenate the parameters.
Allow secrets to be referenced by secretId within the connection string. The AVEVA Adapter For RDBMS can substitute the reference with the secret's value to form the connection string that it uses to connect to the data source. If the secretId changes, then the reference should be automatically renamed accordingly.
