I'm currently preparing a set of Node-RED flows and use cases for my students in order to motivate and encourage them to invent and build web sites and REST services without having to know, learn and program much.
As an alternative to using Node-RED on its own, I've implemented an HTTP server based on Node.js with Express.js including an embedded Node-RED instance.
This server has the following features:
-
HTTPS with optional HTTP-to-HTTPS Redirection
the main server handles HTTPS only as it is becoming increasingly difficult to deliver pure HTTP content to browsers (even locally). If desired, an additional auxiliary HTTP server may be started which redirects incoming requests to its HTTPS counterpart - Proxy Support
-
Support for "self-signed" or "Let's Encrypt" Certificates
for local tests, it may be sufficient to generate self-signed certificates (instructions can be found in the server manual). For public tests, the server also supports certificates generated by "Let's Encrypt" -
Support for "virtual Hosts" and Subdomains
the server may optionally support "virtual hosts" and serve multiple domains (including subdomains) simultaneously. In this case, each domain will be mapped to an individual file system subtree in order to isolate the domains from each other -
"www" Subdomains
if desired, "www" subdomains can be mapped to their original domain (since they usually serve the same content anyway) -
embedded Node-RED runtime
incoming requests will first be compared to the entry points given by "HTTP in" nodes - and their flows be executed whenever the URL paths match (if "virtual hosts" are to be respected, all these entry points become domain-specific and their paths must therefore be prefixed by the domain they belong to). Requests not matching any "HTTP in" node entry points will then be used to serve static files from the file system (or generate a 404 response if no matching file could be found) -
embedded Node-RED editor
the embedded Node-RED editor is generally protected by "basic HTTP authentication": for that purpose, the server always comes with a "User Registry" which already contains a single user (named "node-red" with the initial password "t0pS3cr3t!") who is allowed to access the Node-RED editor -
Path-specific static File Protection
most static files on this server may be available to the public - but perhaps not all of them. For that purpose, this server allows to specify which files should only be available to specific users -
User Registry with PBKDF2 hashed Passwords and Role Support
the list of registered users is stored in a JSON file with passwords saved as PBKDF2 hashes with random salt. While the server itself does not contain any user management, such a feature may easily be added as a Node-RED flow - although, in fact, a simple text editor is already sufficient to add new users, change existing ones or remove obsolete users -
Path-specific CORS
"Cross-Origin Resource Sharing" may be configured for complete sites as a whole or for specific resource paths with any desired granularity -
configurable "Content Security Policies"
the server is secured using Helmet with a configuration option for specific "Content Security Policies" -
standard-compliant Logging
access logging is done using morgan. Logs may be written into a file either in "standard Apache common log format" or any other format
You will find it on GitHub, feel free to use it in whatever way you want. Any feedback is welcome.
With greetings from Germany,
Andreas Rozek
