Hi all!
Is there a way to access the HTTP/Express app instance in a function node?
Hi - no, it is not exposed to the code in a Function node.
What are you wanting to do?
I aim to integrate SocketIO with the existing HTTP server. I'm aware of the availability of SocketIO nodes for installation, but my preference is to implement this within a function node, specifically during the 'on start' and 'on stop' events.
I believe it's feasible to design a custom node that grants access to the HTTP server via the msg object, correct? If so, my approach would involve triggering an injection on startup, followed by configuring SocketIO within a function node, and finally setting a global property to maintain this setup.
Thanks!
I think you need to explain what outcomes you expect from that setup. It is certainly not an expected approach. Doesn't mean it is wrong but I don't believe anyone has ever looked for that before.
Why socket.io specifically? And why expose socket.io/express to a function node? This could be quite unsafe depending on who had access to that configuration.
On the other hand, if you want integrated access to web pages with real-time comms, then UIBUILDER and Dashboard already give you that. Each in different ways.
Thank you for your response.
Regarding the expected outcomes, I primarily need the socketio in various function nodes. It's important to note that I neither use nor plan to use uibuilder or dashboard in my setup.
Additionally, could you please elaborate on your previous comment: "This could be quite unsafe depending on who has access to that configuration"? I'm interested in understanding the specific risks and implications associated with this aspect.
If I may,
Having access to the underlining server is just not a thing in "userland" if that is the right word here?
I would instead look to develop your own nodes for your purpose.
This gives you access to RED.httpAdmin which is more relaxed with access.
there will be a requirement to understand the make up of a node, but I feel this is more were you need to look.
RED.httpAdmin is an express instance.
But you haven't explained WHY? Without that we can't help that much. Node-RED already has websocket nodes.
Because whoever has access to alter flows would have access to lots of internals that are normally reserved and not accessible. It would be easy for someone to alter a flow and break everything or to intercept traffic and either record it or change it.
Might not be an issue if you only ever have yourself writing flows - but even then, it would be all too easy to break everything.
Function nodes run their code in a restricted environment for good reasons.
Accessing Express or websockets from a function node is simply not a good idea in general. If you really must do it, you will need to write a custom node as Marcus say's.
I'm having some difficulty understanding your reference to a function node being in "userland". From my perspective, nodes are capable of a wide range of operations. For instance, the exec node can execute arbitrary terminal commands. In light of this, I'm curious about how hosting the Express server instance within a function node poses a greater risk than using nodes like exec. Could you provide more insight into the specific dangers associated with this setup?
I will create a custom node that exposes the RED.httpAdmin to the msg object.
Lets try this....
The document editor (or document is a better analogy) in say, Microsoft Word is "Userland"
the internals of MS word is not?
I understand your concerns regarding the potential risks associated with modifying flows and intercepting traffic. However, I believe this applies broadly to any code or program. If someone has the capability to alter the system, they inherently possess the ability to manipulate or damage it. This seems like a general risk, not specific to the situation I'm inquiring about.
Regarding the ease of breaking everything, I'm curious how this differs from any standard Node-RED setup. If an individual has access to the flow editor, they could potentially disrupt any flow, not just the setup I'm proposing. Could you clarify how my suggested approach is more susceptible to being compromised compared to a regular Node-RED flow?
As for function nodes running in a restricted environment, I'm trying to understand why a function node is considered more harmful than nodes with broader capabilities, like the exec node. It seems somewhat excessive to restrict access in function nodes, especially considering that system administrators are expected to responsibly manage and utilize the full extent of Node.js capabilities.
I understand the concept of "userland" in the context of software development. However, in the case of Node-RED, users typically interact with the system through a graphical interface to create and manage their workflows. Imposing restrictions on access to certain internal features can seem overly protective, almost like babysitting experienced users.
While I recognize the importance of safeguarding against potential misuse, it's also crucial to acknowledge that skilled users might have legitimate and innovative reasons for accessing these more advanced features. By overly limiting access, we might inadvertently hinder the creative and functional potential that Node-RED can offer to adept users. Therefore, I'm advocating for a more balanced approach that respects the expertise of users while maintaining necessary safeguards.
I suppose my view will be…
Let’s use my MS Word example;
If a user wanted to do advanced things that go beyond writing an MS word document, they will look to develop a plugin to MS word.
In the same way, they will need to develop a Node RED custom node.
Both approaches will provide more control over the “Editor” and accessing the internals
I realise I am comparing Node RED to MS Word, but hopefully I make some sense 
The exec node can indeed be harmful if not careful, it can be disabled if needed. More importantly, if allowing other people to edit flows, you should be restricting what node-red itself can do, mostly using control of the user id that runs node-red. While you can't stop node-red from changing the flows file, you can stop it from changing settings.js and other critical files and folders.
System admins should not be running node-red unless that is your explicit intent. As I said before, this all depends on who has access to the node-red editor.
If your requirement is to run node-red for your own use and not exposed to the Internet, then it doesn't matter. If your intent is to run in a corporate environment with potentially multiple flow editors then the risks are a lot different.
I really don't believe you will find much support for exposing the internals of Node-RED to function nodes. But I'm only another user, others may disagree.
Also, the current configuration is really not hindering creative use. It is absolutely possible to create a contributed node or set of nodes to do what you are asking for. That gives people the option to allow such access if they want it without changing the nature of the existing controls in Node-RED's core. That is the nature of Node-RED.
And that's just it. Many (most?) Node-RED users are not programmers with experience. Node-RED allows people with limited experience to create automations and processing. Those with the experience can create custom nodes to do more advanced things.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
