Feature Request: Please add credential input to Inject and Change Node

Core Development Feature Requests
1

Hello,

I communicate with multiple instances of the same API.

I have common flows; the only difference is the host and the credentials.

I use a change node to set the message values passed into the connector.
However, I have the credentials in plain text; it would be great to have a credential input in the change node and the inject node.

TIA
Harry

2

Hi @HarryPottar

I've raised FR: Add credential type to Change/Inject nodes · Issue #5063 · node-red/node-red · GitHub to track this request.

One workaround available today would be set env vars on the Flow properties (which can be set as credentials) and then reference it in the Inject/Change nodes as env property. That may be a good enough solution to not warrant adding anything new to the nodes - but we'll see.

Nick

2 Likes
3

Thanks Nick,

I know how to system level, and sub flow environment vars, how do you set env var for a flow(tab).

Thanks
Harry

4

Open the tab properties and there is an env vars sub-tab. Was introduced ~v3

2 Likes
5

Groups also have that capability.

1 Like
6

I'm using a third party node 'credentials' to safely store secrets in a flow.

7

I use .env file for all my secrets (independent of node red). My secrets are scattered all over, for example in urls or other fields which isn't covered by node red. I think the whole idea of having a built-in password vault is doomed to be incomplete because secrets can be used in so many places that will be infeasible to cover systematically.

8

Just remember that environment variables are NOT a security feature :slight_smile:

They are fine as long as nothing has access to the OS - if it does, then the content of the variables can always be accessed I believe. (Hint - Node-RED has access to the OS!).

1 Like
9

Yeah the secrets are used by node red, so necessarily it has access to them. What it does is remove all secrets from source code, so source control or copy-pasting won't compromise anything. That's more than the built-in encryption in node red does anyway.

10

Sorry, for clarity, the point I was making is that the OS holds the environment variables in memory so any app that has access to OS features can read or even change the content of those variables.

In NR's case, if, for example, you had a cloud service password in an env, any application on the server could get hold of it. That includes but isn't limited to NR. But in NR's case, anyone with access to the Editor can display all env variables if they want to. So environment variables can only ever be considered a CONVENIENCE and NOT a security feature. Too many people forget this.

1 Like