Hi @kienerj , this is getting very interesting As I said, not knowing the exact context of @stevelp request, I provided a way to help with what he was looking for and does not store passwords in plain text. The use of the component was to be able to change the credentials in one place for multiple workflows if another coworker of his uses the workflows. @stevelp , I hope you can adapt what is being discussed here to your needs - I feel like we’re “hacking” this thread lol
@kienerj , I would not include the connector in the component simply because I tend to separate processes/functionalities, although in this case, come to think of it, it does make sense that the credentials go with the connector since they’re exclusive to the connector.
Regarding the input from the component itself, are you using the “Save Password” option? It does not lose the credentials if you have the Save Password (I tried it and confirm). Well, to clarify, if I save the workflow after changing the credentials via the component UI like you did, the new credentials are saved in the workflow. And obviously, if another user opens the workflow, he/she will have the last saved credentials - again, I don’t know the exact context on how you guys use your workflow. And obviously also, if someone changes the credentials in the source component, this change will overwrite the values of the linked components in the workflow.
Regarding the weak password encryption, I don’t have much info about it and I am not a fan about it because of this. I’ve wondered the same questions you are asking, but it’s still better than plain text in the end.
In general (not always), I usually use the method I mentioned for app db user (basically a shared user), and for workflows that use user credentials, I usually set it and the connection string at the workflow level:
This will prompt the user to enter his/her credentials and not save the password
Another way I use and want to share with you is in relation for adding multiple environment credentials to the workflow (obviously you don’t want everyone to have access to these credentials, only a couple of superusers). I put together a quick example (that is why you do not see them as linked components, but in my real workflows, I have linked components for these):
The Environment Selector allows you to choose which env you want to connect to:
And here’s the inside/details of the “Set Connection Configuration” component:
In the end, what we choose or how we choose to implement something all depends on the situation and use-case. I hope you can adapt some of these to your needs.