Hi! I use node red as a small home automation. I want to show some things to the outside world (things like temperature values, graphs, buttons, slider), but at the same time not give access to the entire dashboard.
I have an additional frontend system with nginx on my local network that supports wordpress sufficiently. It doesn't have to be wordpress, you can use any lightweight CMS or plain html (html is preferable).
What are the possible solutions?
Welcome to the forum @MaximusPauls.
A Node-red system exposed to the internet is an attractive target for hackers because Node-red is often weakly protected yet has privileged access to the machine it runs on. These can be fixed, but it's not straightforward.
Instead use a cloud based server to run a separate copy of Node-red. Use strong protection for the editor.
Send just the public data via MQTT with a cloud based broker to update the external system dashboard.
What @jbudd said is good advice.
I would probably generate HTML and get your webserver to handle it and use Imagemagick to generate jpg's from node-red
That's what id do obviously depending what your doing and who for etc
If you want to stick with Dashboard, you will have to build a second node-red instance. Just make sure that you only allow access to the Editor from your local network, not the internet.
You can use NGINX for that or even better, use a service such as Cloudflare Zero Trust which is even more secure. They have a generous free tier and you can do authentication there as well.
If you can think beyond Dashboard, UIBUILDER will give you a lot more flexibility and will let you easily build as many different web endpoints as you like. You could do that from your original Node-RED instance or a new one. Either way, you can use either NGINX or CF ZT to secure it.
If you drive your dashboard entirely through MQTT, keeping any associated logic to other flows, then you can easily copy the parts of the dashboard that you want visible and run them in a different instance of node red. It can even be on a different computer.
Displaying things vs controlling things are 2 different flavors. If you only want to display things, you could 'render' out complete html from node-red and upload it to some other server (or only upload json/csv data and have the html process it), then you keep node-red completely separate and still have a 'view'.
I also considered the option of generating static images and html.
I was hoping to find a ready-made solution for interactive interaction. graphs with zoom and some real-time interaction.
Perhaps uibuilder is a bit difficult for me. Its capabilities exceed its potential needs.
I don't want to study all rocket science for the sake of one glass of water.
"KISS" If you know what I'm talking about.
As someone who does have an exposed Node-RED in the internet and here is the address.
You can expose an NR to the internet but ideally not a full blown server. My NR is in a docker container hosted on Heroku. There is not much anyone can blow up there.
Second strong password and username is always good - don't use "root" or "admin" or "user" as username, so something like "7CsiPEg4zZBKaIutUdeIWHVDC4EXDmWH" as username is great ... or wait, that's my password.
Third don't use the top level domain for your editor path, i.e. if you hosting your node-red flow editor on the domain https://this.where.nodered.is then change the admin path to something like bananasareyellow, so that your top level domain returns 404 while https://this.where.nodered.is/bananasareyellow becomes the flow editor with a user + password combination.
Fourth never, ever share that url - never send it across the wire via emails or messenger. Keep it for yourself. The point is that messenger apps access the URL via their preview functionality, then they index that URL and then you get robots knocking on the door.
The domain I've setup using NodeRED is https://blog.openmindmap.org - now on that domain the editor isn't located, it's on nodered.openmindmap.org, i.e. a different subdomain - no not, nodered.
The subdomain is also random.
Now, none of this this "security" remember, this is "obscurity" - and I'm well aware of that.
Also it's surprisingly easy to figure out all subdomains of a TLD (via ssl certificate registrations for example), so don't think that having a subdomain will protect against people finding the right endpoint. It's still a game of hope and sleepless nights.
Hence also have a good backup scenario so that recovery - in worst case scenario - is fast and simple. Hence a docker container with a "read-only" instead of Node-RED is ideal.
"read-only" because NR reads in the flows.json once and then it sits in memory. Changes can't be made because the flows.json is in memory and/or statically stored in the docker image.
Well, you already mentioned HTML - and that's enough because that's all that UIBUILDER covers really! It is simply a way to link your Node-RED server with HTML for the browser and to serve it all up. It looks complex - probably because there are so many options. But in reality, you might want to try the walkthrough, there is a matching video as well if you wanted it.
And I totally agree. But simplicity can be different things. In UIBUILDER's case, the simplicity is in use, the complexity is completely hidden - until you need it. Then you discover everything that HTML can do is still right there waiting.
I'm afraid to give internet direct access to nodered. With uibuilder, I will have to do this.
Maybe, the bad guys won't be able to control my nodered, but they will be able to stop it with a large DDoS of requests.
An additional point is the separation of user rights. Guests should not see too much. Children have more viewing rights, but they should not have control rights.
I think nginx frontend on a dedicated DMZ will solve this issues.
No, you don't have to at all. 
You should always use a proxy between the outside world and your node-red based services.
UIBUILDER recognises common proxy authentication headers so that you can use them in your front- and back-end (node-red flows) processing to limit access however you like.
My recommendation, especially if you aren't familiar with Internet proxies and cyber security, is to use a service such as Cloudflare's Zero Trust service. This provides a cloud proxy along with authentication and authorisation capabilities. It has a generous free tier and it does not require you to make changes to your local firewall or network. There are other similar services.
If you want to DIY, then something like the NGINX web server acting as a reverse proxy along with a suitable user authentication server is what you will want.
Even without user authentication, you can easily configure a reverse proxy to ONLY allow internet access to a UIBUILDER endpoint. And, of course, unlike the Dashboards, UIBUILDER lets you create MULTIPLE endpoints very easily. So you could have some with user authentication and some without. Or you could use the same authentication but have different authorisation. The choice is yours.
Whilst this is true - and another reason for wanting to use the Cloudflare ZT service as anti-DDOS is built into their offerings. It is the absolutely least of most people's worries. Large-scale DDOS attacks are not easy to do and attackers would not bother to attack some random person on the Internet with DDOS - automated hacks, sure, but not DDOS. You would have to be presenting information that someone was actively interested in. Perhaps a political site against a rogue government, or outing some hacking group for example. And in any of those cases, you would be foolish indeed to use your home network for that!
It will, if correctly configured. I still would not expose the Node-RED Editor though. I certainly don't. Though I do have a secret way to remotely turn on remote access to the Editor should I ever need to. But it is left turned off and uses a very obscure, but still secured, mechanism that lets me turn it on/off as needed (I never have needed to).
A well configured Node-RED flow set really should not need interventions. If you need some limited external controls, use a Telegram bot or something similar.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy