Credentials (and file names).... Not quite clear on something

Granted I have done this on ONE of my machines.

But the story is not that simple.

So, background:
Machine (.99 TimPi) I tested the credentials settings.

I edited the settings.js file to what is needed to force log in to the edit screen.

For external reasons I could not log in. I could enter the name but not get to the password field.
Given that, it was rather pointless keeping that setting active, so I remarked out the lines in the settings.js file and all seemed ok.

To the best of my knowledge this was the ONLY machine to which I did it, as this was really the only one which had a chance of constant internet exposure.

Obviously the others can be exposed to the net for updates, etc. Risk assessment: Not worth the hassel.

Since then that machine has gone belly up. Whole other set of problems. But it does arc back to it in some ways.
I updated the OS (RPI) from Jessie to Stretch.
This caused problems for me, as most of mine are still running Jessie. But a couple of new ones are on Stretch.
---------------------- New machine introduced here.
So, to get needed information I went through looking for one with Stretch.
(.94 BeefPi - yeah: THAT one.) is running stretch.
Loading its page, I was (I think) notified about a credential conflict. (What credential conflict?)
Looking in the .node-red directory it has an extra file as Nick explained to me was to do with me successfully activating the secure log in.

But I didn't - on THAT machine.

----------------------- Another machine introduced here.
Also, the file names:
As this one is called BeefPi, it was weird that there were some called "PiFace" (.86) (another of my machines)

Yeah, ok. I have cut/pasted flows from one to the other, as PiFace is/was my main RPI machine.
So I would create flows, edit them, etc and when working export them to the other machine/s.

So I am thinking that because the flows were made on "PiFace" and exported they kept their names?
But the cut/past was done at the WEB level, where I would select the flow/or part and export to the clip board then import from the clip on the new machine.

So that is what I know.
I'm not losing too much sleep on that part, as it is only a file name. It is just the "discrepancy" that has me interested.

1 - Why does a machine on which I have not done the secure log in settings have the file?
2 - The file names..... Just wondering why I'm getting file names from other (one at this point) machine on a different machine.

(Is that clear?)

Thanks in advance.

Because regardless of whether you have set credentialSecret or not, you will have a credentials file if any of your nodes have been configured with credential properties.

As a user you won't know what property is stored where from the UI - it will depend on how the node has been implemented.

For example, the HTTP Request node lets you enable basic authentication and you provide Username and Password. Those two properties are handled as credentials so will end up in your credentials file.

If none of your nodes has credential properties configured, then the runtime will not create the credentials file. If any of your nodes do have credentials configured then you will get the file.

We cannot answer that for you. That will be a result of you copying things around or renaming the machine (as by default NR uses the machine name as part of the flow file name).

1 Like

I think you are getting confused by a basic thing here - the credentials file is created to hold encrypted credentials of SERVICES that your flows may access. This could be for example the credentials to login to the DarkSky API for weather information, the credentials to login to a Web based service like IFTTT etc etc.

Changing the Setting in the main settings.js file only changes how those credentials are encrypted and stored on disk i.e. are they encryped using a machine level password (that you do not know about) - or a USER supplied password so you can retrieve them later when recreating the machine etc.

The Username and Password you supply at the Web Interface to login to the Flow Admin (and User/Dashboard) screens are completely different and have no relationship to the credentials file you are talking about.



Thanks Nick, Thanks Craig.

Thanks. It is kind of refreshing that someone else admits they can't answer a question.
I speak to many people and it seems they aren't able to do that.
I really appreciate your honesty there.
Renaming the machine: Never happened.
The ONLY thing that comes to mind is the new SD card with the new OS build. But that's clutching at straws.

So if all I have done (once as trial) was set up the passwords for logging in to the GUI/edit screen you are saying is something else?

Wow. Another "monster"/gremlin? in there. Oh well.
But as I explained, there is a problem with other stuff on the machine which prevents me logging in and using that system.

Ok, so there are different ways of securely logging in.
The password option,
using a remote machine to act as a validater (?) to confirm it is "you" logging in.

Ok, the problem I have is LOCAL and my "fault".

Is there a way I can set up the "third party validation" to be done locally from another machine on MY network?

(Although with the given caveats, saying the network is not connected to the internet)
And this other local problem which I am going to have to look into myself.

Say I want to lock people out of editing the flows?
Yeah, I have made it difficult for myself with this other problem, but....... "it happens" and I am only asking if there is a way to use one of the other ways to do the "third party validation" but that machine is local.

I'll shut up now.


Ok.. so we're switching subjects back to securing Node-RED...

I thought you had adminAuth all working? You say it's working here: The password/security settings article mentioned on the page - #29 by Trying_to_learn

You'll note in this thread you share the node-red log with us ... so you could bookmark that thread as well to help remind you in the future.

I'm not really sure where you are getting the idea of using a remote machine to act as a validator... that isn't something I'm aware of.

You should use adminAuth as discussed in the previous thread I linked to above and as documented here: Redirecting…

Nope you are getting confused again.

When you edit settings.js and set the adminauth info in there that is the username and password that you will use in the web interface to login to that instance of node-red on that machine.

The credentials file is used by nodes within the flows on that machine to store encrypted credentials to login to remote services (the examples i gave were things like your Darksky API key, your IFTTT credentials, any remote websites, FTP servers etc etc.

Think of it like this

  1. I create a new flow and want to retrieve weather info for my location.
  2. I therefore go to the Darksky website and create a username and password and get my API key and credentials
  3. I then insert them into a node in my flow so that flow can login to the website on my behalf and download information.

That credential information has to be stored somewhere - you could just be insecure and store it in plain text inside your flow file - but this would not be a good decision and is not what the node-red developers have chosen to do. Instead that information is stored in a seperate encrypted file that can be retrieved by the flow when needed.

Now by default the encryption for that file is managed by that machine and is given a "machine" password that you are not privy to.

In the event that you move those flows to another machine - they credentials to those remote services (Darksky in this example) - will have to be retireved (by you) from the website, re-entered into the flow before it will be able to access the website again.

On the other hand if you choose to set your own password for the encryption of that file - then if you move it to another machine you can re-enter that password in the settings.js and alll your flows will work again.



1 Like

@craigcurtin yes, I think that is understood. The thread has pivoted to talk about how to setup username/password to access the editor... something we've already discussed with @Trying_to_learn but it appears we maybe didn't resolve his issues in the previous thread.

Yeah not so sure we have the credentials thing nailed down in his head yet

Lets hope so though !


So reading this on the link you procvided:

To use an external authentication source, Node-RED can take use a wide range of the strategies provided by Passport.

Node-RED authentication modules are available for both Twitter and GitHub. They wrap up some of the strategy-specific detail to make it easier to use. But they can also be used as a template for authenticating with other similar strategies.

The following example shows how to configure to authenticate against Twitter without using the auth module we provide.

What ever it is or what ever you call it......

I am asking can I have a local "external authentication source" which is on MY network. NOT the internet?

I'm guessing the answer is NO. Ok.

But I'm confused (as I am sure you are) why it is that difficult for me to ask the question and to be understood.

Ok, I "don't know what I'm talking about" WRT the credential thing. Funny I thought I do.
So if it is NOT (taking the first option) that I edit the settings.js file and then have to enter a "username" and "password" to log into the page and edit the flows, what is it?

Because when I edit the settings.js file and (reboot, blah blah) and go to the web (edit) page I get the log on screen as per:
(see attached)

So maybe for everyone's edification I had better be told how what I think is different to what it really means.

(Ignore the red lines. They are part of the other LOCAL problem with other programs and passwords I am having.)

If you read the documentation you will see:
To use an external authentication source, Node-RED can take use a wide range of the strategies provided by Passport.

So if you want to use an 'external authentication source' but inset it locally on your network, it would have to use Passport. If you follow the Passport link (provided in the documentation) you will see there are over 500 ways to do it.

BUT you need to ask yourself if this is another rabbit hole you want to go down, becasue you would have to install one of these on your local network and get it to work.

1 Like

Hi @Trying_to_learn

Yes, it is possible to plug in custom authentication modules. We provide examples for Twitter and GitHub. You want to do something that we don't provide an example of - so you'd be on your own to implement it from scratch for yourself. But to be frank, I don't think that is practical for you to attempt unless you are comfortable writing a lot of node.js code yourself and have a good understanding of what you actually want to achieve.

I don't understand what point you are making with all of this.

Everything you say there is exactly what you are expected to do: edit your settings file, setup adminAuth, restart Node-RED and when you try to view the editor you will get what you see - a login prompt. We've explained that a couple times in this thread and in the previous thread on this topic.

1 Like

I am only looking at OPTIONS.

Alas there is a "problem" I have.
(Sorry story)
THIS machine is a NUC. It is my main machine which has ball$, so surfing the net, etc is no worries.

I have another RPI TIMEPI ( which is my main NR machine, NTP server, and WAP.
It is a RPI 2A I think. Old one.
That machine has the best view of the real world, and I ONCE tried the login thing with username and password.

BECAUSE THIS machine has another program for passwords, it all fell over with that.
I'm not (yet) 100% sure if it is the problem, but until then, I can't have the log in active and use it from the NUC because of stated problem.

As an option, I was asking (note: ASKING) if I could use a local machine to act as one of these "third party" units.
It is going to need a lot of work and stuff beyond my knowledge base.

I'll have to let the whole idea go. But I was just wanting to ask.

So, I will have to get the time to go through the debug of logging into the TIMEPI (with validation) from another machine without the password software and see where the problem is.
Granted: That's MY problem.

But THAT task is way down the priority list because the TIMEPI machine needs to be rebuilt from the ground up.
So I need to get the NTP server working and then get the WAP working.

It doesn't stop me asking.

I AM sorry if I don't always remember. (Think how frustrating it is for me! I have to live with this "problem" of not being able to remember things. and there is a limit to writing everything down. It just gets beyond practical with some things. But again: that's MY problem. But please don't get angry with me because of that.)


Yes, I think that is another rabbit hole I do NOT want to go down at this point.

I just explained to Nick, I believe that is beyond me at this time.

I have a lot of local debugging to do but there are a few other tasks higher in priority just now.

(Seriously, I am out of my depth just now because of a recent machine packing it in, and having to rebuild it.)

Right here is an update:
(If you are still reading)

Today I powered up the RPI.
Went in, edited the ~./node-red/settings.js file.

Activated the log in:
(See below)

    // Securing Node-RED
    // -----------------
    // To password protect the Node-RED editor and admin API, the following
    // property can be used. See for details.
//  New stuff for password.
    adminAuth: {
        type: "credentials",
        users: [{
            username: "me",
            password: "**(Yeah, right)**",
            permissions: "*"
//  End New stuff for password.

(and before you say it: Yeah, I deleted the encrypted password)

And powered up a VM running Ubuntu 18.04.
There is no extra software running for local password managing as there is on THIS machine.
Loaded FF.
Went to the IP address.

Got the same log in screen as previously shown.
Entered the name:
Can NOT get to password field.
Every time I click in it, the cursor jumps back to the username field.

Any thoughts?

It probably has to do with the password since it is not encrypted - go back and read the documentation

To CLARIFY this:
I have a password, the encrypted part WAS in the line and I replaced it with (YEAH RIGHT)
(Bites tongue)

The REAL password is encrypted.

A while back I went though the process of making the password and getting it all "working".
That was until I tried to log in and got stuck at the password field.

There was a sticking point with THIS machine as it has other programs to handle passwords running - as it is also my MAIN machine.

The one with the NR passwords is a RPI and remote.

So, until I resolved that issue with THIS machine it was a bit moot.

For reasons unknown, tonight I booted up the RPI and went to the .node-red directory, edited the settings.js file to activate the log in.

Tried it from THIS machine and the problem remains.

I powered up a VM running Ubuntu 18.04, up to date. Loaded FF, no addons, not extra software.
Went to the RPI IP address.

Got the requestor.


So, as I see it, the problem is NOTHING TO DO WITH THIS MACHINE AND THE EXTRA SOFTWARE DOING PASSWORDS and rather at the RPI end.

So, as much as it is giving me the log in screen, it is 100% pointless if I can't enter the password I generated/used when I set it up.

That is certainly an odd behaviour I cannot explain. What browser are you using?

What happens if you go back and bcrypt the password and put the encrypted version of the password in the settings.js and restart NR on the machine that you just edited settings.js??

@zenofmud that is exactly what Andrew has done. The current 'issue' is the browser doesn't let him enter a password in the UI.

Ahhh, the long and convoluted post confused me.

Well I just added @Trying_to_learn settings to a pi and started up NR and from my MAC, I tried to connect using Safari, Chrome and FireFox. In each ine, the login screen came up with the password field but of course I can't log in because whatever password I enter - when the software bcrypts it - does not match the bcrypted version that is in settings.js