Hello
I am having a weird issue when a flow sometimes loses its credentials stored in the environment variables and replaces such values with the default "__PWRD__".
The easiest way to reproduce this issue (although I think there are other cases when this issue appears) is as following:
run Node-RED in a Docker container;
set up environment credentials;
verify that they work (e.g. connect to a server with the stored password);
restart the container;
add another plain text, non-credential environment variable.
Bam, the "credential" variables are converted into "__PWRD__" and the flow becomes unusable. Other flows seem to be not affected.
credentials are deliberately removed from the flows and are DELIBERATELY NOT exported.
They get encrypted into a file named something like flows_creds.json
That is not to say you are not seeing some kind of bug, however your steps are not detailed enough. For example, you dont say if the container has a mapped persistent data dir, how and where you enter these "environment credentials"
credentials are deliberately removed from the flows and are DELIBERATELY NOT exported.
Yes, I understand that. I am not trying to export them, I'm trying to use the flow. Once I realised that after some time my flows start randomly failing because of missing credentials I've added a whole setup to walk over flow + env variables to verify that they are all there. And sometimes they aren't — API calls fail and debug shows __PWRD__ instead of the real value.
how and where you enter these "environment credentials"
Through the flow parameters. Double-click the flow tab, click on the "Environment Variables" tab next to the "Done" button.
you dont say if the container has a mapped persistent data dir
Yes, it does have a persistent data dir. Flows survive container restart. Even entered credentials survive container restart. Yet once I edit env variables credentials are suddenly lost.
Now I found something weird. When I navigated to the Node-RED data dir (either inside the container or on the host machine) and ran ls -la it said Jun 20 13:03 flows_cred.json which doesn't sound about right... Credentials were modified more than two months ago? Definitely not.
I do have a node installed node-red-contrib-flow-manager to split the one huge flow into separate flow files. Yet it shouldn't touch the credentials, I think.
Which credentials specifically. What are "env variables credentials"? In Node-RED, env vars are simple key/val pairs! Do you mean you entered (for example) a user name and password in an MQTT or HTTP node then they are lost when you edit a TABs env vars? What type of deploy do you do (full/flow/node deploy?) Are you editing the same tab which has a node with credentials? Are the credentials actually lost (e.g. does the node fail to login to the "thing" or is it a visual thing only)?
Please provide step by step repo that I can try out.
BUT - before this, I would consider testing this on a node-red instance without node-red-contrib-flow-manager to see if you see the same thing.
Thank you for trying to debug the issue with me.
I've reproduced it on a fresh Docker install:
run via sudo docker run -it -p 1881:1880 -v nodeRedTestData:/data --name noderedTest nodered/node-red;
add flow envirnment variables ("plaintext:plaintext" of type string and "encrypted:encrypted" of type credential. Key equals the value in each case);
make a simple flow to read those env variables by their keys, add to msg, and print to debug (print "complete msg object");
deploy everything by Ctrl+D;
on the host machine quit the docker process killing it, restart via sudo docker restart noderedTest;
load the flow, run it. All values are printed correctly, as expected. "Encrypted" value is decrypted and available in the flow;
edit flow env variables, adding a new plain string variable;
deploy by Ctrl+D;
run the flow. Encrypted variable is lost and prints "PWRD" instead.
After that I slightly edited he flow (to print the new plaintext variable as well) and ran it again. The encrypted variable is gone.
Attachments:
'environment variables' screen where I add/edit the variables. Here it shows the state after I added the second plaintext variable, after container restart:
debug panel output with three msgs printed: after restart (decrypted variable visible ok), after adding another plaintext variable (decrypted variable lost), after adding the second plaintext variable to the output (decrypted variable is still gone):
This just got weirder. I've decided to investigate the 'flows_cred' update time (it looked weird). So I kept alternating adding credential, plaintext variables and restarting. And they randomly get lost and reappear. So they are not lost forever, rather being temporarily unable to be decrypted when another env var is added.
So far I've seen:
one encrypted gone (converted to __PWRD__) the other available,
both available again.
I've just tried:
adding an encrypted variable,
restarting the container,
running the flow,
adding a plaintext variable,
running the flow,
restarting the container.
Things are different pretty much every run. I do not understand why sometimes the credentials are lost
I am not seeing what you see! This can be due to many factors. e.g. what deploy mode you use, how long after deploy you restart node-red, how you perform the restart (deploy menu reset? stop/start container?), the order you enter values (plain ~> encypted ~> plain etc), etc, etc
In short, I need a reproducible set of steps.
Something like:
starting from a blank Node-RED
add a plain env var named name, value fred to the flow/tab env vars
add a credential var named pass, value pass to the flow/tab env vars
deploy using (full?/flow?/node?) deploy mode
restart node red by doing x/y/z
refresh node-red
add this flow [{xxxxxx}] and press inject
note how you can see x/y/z
add a plain env var named title, value testing to the flow/tab env vars
etc
etc
EDIT:
I realise you posted a step by step above, but it is missing much of the detail as mentioned above in this post (deploy mode, timings, no demo flow). Needs to be ultra specific and repeatable. Ta.
@Steve-Mcl , I think the bug has been fixed in Node-RED version: v3.1.0
I've asked a colleague to help me reproduce the bug. He couldn't. I asked him to go step by step with screen sharing — I had the bug and he didn't. Then I noticed that his Node-RED was slightly newer. I was running Node-RED version: v3.0.2. docker pull nodered/node-red — now I also have v3.1.0 and I cannot reproduce the issue any more
