Here are some of the changes I contacted you about.
Unfortunately a few months later than expected ...
A http endpoint is added on the backend to generate a keypair, and a button has been added to the frontend to call the endpoint.
The 3 keys aren't anymore plain text fields, but are now converted to Node-RED credential fields.
Button to generate keypair
To avoid the users having to use command line stuff, I have added a button to generate a keypair:
Some remark:
The confirmation popup is only displayed when one of both fields already contains something.
The endpoint has been secured by needsPermission. So only users specified in the settings.js file (with write permissions) will have access to the endpoint. Although not really necessary, since anybody is allowed to generate a new keypair ...
Keys in credentials
Until now the 3 key fields were plain text fields, which has some disadvantages:
When you export a part of your flow (to share with others), your key fields will also be exported.
The keys are visible to everybody that has access to the flow editor.
The keys are stored in the flow.json file as plain text.
The keys will be transferred over and over again between client and server.
The keys will be readable by all other (malicious) nodes.
...
To solve that, every Node-RED node has a 'credentials' section where I'm going to store the keys.
The major part of the work was to migrate the plain-text keys of old existing nodes to the new keys in the credentials, to make sure we have no impact on existing flows:
I had to keep both the old html elements and the old node fields, otherwise Node-RED messed up the old values behind my back. The new fields have a postfix "2.
As soon as you enter the keys manually (or via the new generation button), the keys will be temporarily be available in the browser:
But once you have deployed the flow, the keys are only available on the server. From then on Node-RED will only send to the browser whether the key fields have content or not:
So this is much better compared to passing the keys all the time between client and server ...
As long as we keep using input fields of type 'text' you would see indeed that Node-RED only sends dummy text content to fill the html fields:
Therefore we will change the input fields to type "password", to display the dummy text like this:
Should be much secure now...
But there is something that is still not correct ;-(
Node-RED makes sure that nodes can only read their own credentials, so other nodes cannot access them! However the keys from your config node are also needed in your web-push node. This means I had to add a new function to the config node, to get access to the keys:
And that function is now called from the web-push node. But this means that all other nodes can call it to read the keys, which is NOT secure!!
Would be better if the config node had following two functions:
A getPublicKey function (which I have to call from my new dashboard UI web push node).
A sendNotification function which contains a part of the code of your web-push node. That is the only way to ensure that the private key is only known to the config node...
Do you have any thoughts about this? We can also start continuing with this pull-request, and afterwards fix this issue ...
P.S. when there are no subscriptions, an error was logged. However since it is very likely that there are no subscriptions at some moment in time, I have changed it to warning:
Is that ok for you?
Thanks a lot for reviewing this pull request !!!
Bart
Hey Maxim,
Here are some of the changes I contacted you about. Unfortunately a few months later than expected ...
Button to generate keypair
To avoid the users having to use command line stuff, I have added a button to generate a keypair:
Some remark:
needsPermission
. So only users specified in the settings.js file (with write permissions) will have access to the endpoint. Although not really necessary, since anybody is allowed to generate a new keypair ...Keys in credentials
Until now the 3 key fields were plain text fields, which has some disadvantages:
To solve that, every Node-RED node has a 'credentials' section where I'm going to store the keys. The major part of the work was to migrate the plain-text keys of old existing nodes to the new keys in the credentials, to make sure we have no impact on existing flows:
I had to keep both the old html elements and the old node fields, otherwise Node-RED messed up the old values behind my back. The new fields have a postfix
"2
.As soon as you enter the keys manually (or via the new generation button), the keys will be temporarily be available in the browser:
But once you have deployed the flow, the keys are only available on the server. From then on Node-RED will only send to the browser whether the key fields have content or not:
So this is much better compared to passing the keys all the time between client and server ...
As long as we keep using input fields of type 'text' you would see indeed that Node-RED only sends dummy text content to fill the html fields:
Therefore we will change the input fields to type "password", to display the dummy text like this:
Should be much secure now...
But there is something that is still not correct ;-( Node-RED makes sure that nodes can only read their own credentials, so other nodes cannot access them! However the keys from your config node are also needed in your web-push node. This means I had to add a new function to the config node, to get access to the keys:
And that function is now called from the web-push node. But this means that all other nodes can call it to read the keys, which is NOT secure!!
Would be better if the config node had following two functions:
getPublicKey
function (which I have to call from my new dashboard UI web push node).sendNotification
function which contains a part of the code of your web-push node. That is the only way to ensure that the private key is only known to the config node...Do you have any thoughts about this? We can also start continuing with this pull-request, and afterwards fix this issue ...
P.S. when there are no subscriptions, an error was logged. However since it is very likely that there are no subscriptions at some moment in time, I have changed it to warning:
Is that ok for you?
Thanks a lot for reviewing this pull request !!! Bart