Last week I had some troubles with my system, which I could easily had solved when I would have been able to run some Linux commands remotely ...
So I thought: how cool would it be if I had some kind of terminal window inside my Node-RED flow editor. That was the kickoff for node-red-contrib-xterm, which offers you such a terminal.
Here is a demo to get the content of my Node-RED directory via "ls -l" on my Raspberry:
This beta version can be installed directly from Github (since it is not available on NPM yet):
npm install bartbutenaers/node-red-contrib-xterm
But I'm completely stuck with some issues, so I can really need some help!
Would be nice if I could have some security feedback (Github issue). Although I assume that the Exec-node also allows users to access their backend commands, I want to make sure that I don't introduce extra vulnerabilities. On my readme page I have added a drawing about the entire trajectory (and a small Security section), which gives you an idea about the setup and used components.
I think the communcation is ok in both directions, since I think I do it the Node-RED way? Perhaps I could give a warning when http (instead of https) is being used (if I could determine that somehow)?
You don't need to enter any credentials in the terminal, since node-pty seems to run with same credentials as the parent (Node-RED) process. Perhaps I could introduce somehow my own login form before continuing, but don't know how to setup something like that in this context ...
Other tips?
The rows and columns can be specified (in number of characters), but that means the terminal calculates his own size (Github issue). But I want the terminal to be resize to fit the parent DIV element. As you can see in my Github issue, the xterm.js process has provided a "FitAddon" for this purpose, but I can't get that Javascript module working. Have tried lots of things, but he doesn't find the constructor ;-( Would really want to have this fixed!
A minor issue: when the terminal is displayed, there is no auto-focus (Github issue). I call the terminal's focus function, but it doesn't work. Perhaps JQuery is somehow specifying afterwards focus on another field perhaps?
I have tested it on Raspbian, but I cannot get it working on Windows 10 (Github issue). Have described my problem in this Discourse question, but unfortunately I had no feedback yet. Would be nice to have a demo animation with MS DOS command line ...
And with lowest priority: I tried for the first time in my life to use Ascii Art, but I can't get it sized properly (Github issue). It is merely a gadget, but would be nice if somebody could fix it for the older users in the community
Looking forward to all 'constructive' feedback.
Thanks a lot and have fun with it !!!!
Bart
Once again, Bart, you seem to be "coloring outside the lines"... nice job! How the heck do you find all this time to spend on these custom nodes?!?
Anyway, I'm confused by the use of a custom node that has to be dropped into the editor in order to open an interactive terminal window to the server. Are you planning on wiring a flow to either the input or output ports? If so, is the idea to pass a unix command, execute it, and pass along the results (which is what the exec node does)?
Unless I'm missing something, what do you think about implementing this as a sidebar panel instead (similar to the VSCode integrated terminal). Then I could just flip over to that panel, it would connect with the server, and I could poke around the system -- which is basically what I do today, but inside a separate ssh window.
Hey Steve,
Thanks!! Well that was initially my idea, but of course there are already nodes available to do that...
Damn it hurts me, but I have to admit that your idea is 100% correct. It indeed felt somehow wrong what I was doing, because I had to put on the readme page that it has no use to use more than one of those nodes in a flow... Had been thinking to create a UI node, but then it would be only available for dashboard users... With your suggestion all those problem are solved.
But I have never written a sidebar node. So now I have to spend even more time on this node, and my next node (that was 95% finished) will have to wait
I've never tried to build a "sidebar panel" module either, but there are a couple that might give you a template to work from -- for instance, node-red-node-swagger. I've always wanted to dig into that node and fix it, but alas, between moving and the upcoming holidays... no time this year!
You probably aren't introducing more issues as long as the terminal runs as the same user as Node-RED which I assume it does.
On the other hand, you aren't helping security either
At the very least, I would include plenty of info in the docs and the help panel to make people aware of the risks. Both about the risks of not using https and the risks of not adding Node-RED admin login.
I would avoid the problems of having your own login/user-change though, at least for now. That could be a later enhancement once you've got the basics nailed down.
And I wouldn't worry too much about http vs https since some of us already bang on about that enough and you will have the info in your help/docs.
Yes, if you haven't already, sign up for a service to check your package and its dependencies so that you are notified when vulnerabilities are found. Your GitHub repo can do some of that but I'd look for a separate service as well. You will want to be on top of that.
Haha . Wanted to mention your name explicit, didn't wanted to push you... Thanks for your tips!
Never heard about that. Can you advise one?
@shrickus: only problem I see is that the sizebar hasn't got the right proportions. A hoizontal bar at the bottom if the efitor would have been better I think. Anyway I really need to get the FitAddon running, but I have run out of creativity...
I use Snyk What is Snyk? - Developer Security Platform | Snyk I couldn't remember it last night. Also check out the settings on your GitHub as they can also do checks. npm audit can also be useful but I prefer getting an email reminder of any vulnerabilities which lets me then schedule in some time to go update my dependencies and push out a new version.
Did a quick test to show the terminal inside the right sidebar:
However it seems to me that I cannot save the settings now? My oneditsave is never called and my default node field values are not loaded into the node.
So now I'm wondering whether it is possible to store data from a sidebar node? And if not, where I should store my settings
Still haven't found a way to store the config settings for my sidebar-panel node. So I tried to move all the settings to a config node. However I'm not able to select any configuration node in my sidebar-panel node:
Would appreciate if anybody could give me tip, how/where I could store the configuration of my sidebar-panel node...
The short answer (as I'm typing this on my phone on the way to sleep) is we don't really have a well defined model for this.
The dashboard does it by creating a ui_base config node - one the user never really knows is there. There's a lot of code in the dashboard to deal with that - there can be only one base node so it has to handle edge cases such as when a user imports a flow that includes a base node.
A key difference is the ui_base node stores dashboard config for the runtime.
Here you are wanting a terminal window in the editor, but presumably you don't want to store its configuration in your flow? Its configuration has little to do with the running flow.
What we dont have is a published API for how to store things in user settings. This is where things like your grid size and other editor customisations are saved - not as part of the active flow.
I could point you at the unpublished APIs, (and I have no doubt that now I have mentioned them, you'll go dig them out for yourself), but they are not ready for 3rd party usage. If we're going to open them up, we need to lay down rules for how they can be used.
We also need to formalise how modules can contribute things to the UI without having to register a node in the palette, as currently that's the only way to get any code loaded into the editor.
Hey Nick,
That is indeed all correct ... The settings are only about the visual part of the terminal (like background color, text color, ...). My backend flow doesn't need those settings, to attach a pseudo-terminal to the shell.
Ok. But don't want you to have to rush for this single node...
Could I perhaps create a temporary workaround (until you ever find some time for the API) by calling my admin endpoint and load/save the settings myself somewhere. Then the settings aren't stored in the flow file, but I could mention that in my readme page ...
Hope you don't wake up this night, screaming my name
Morning Dave,
Thanks for joining the party... My english must be very bad, because I hadn't read your name
Ah now rereading Nick's reply, he means the dashboard's grid settings, and not mine (I also have rows and columns as number of characters). That indeed lakes sense to store my settings there. Is it ok for you to continue that discussion in another post, to keep this one focussed on xterminals?
Thanks very much,
Bart
The second beta is now released, containing a sidebar version. To avoid confusion, I propose we stop the discussion here and continue in this new discussion!
. Wanted to mention your name explicit, didn't wanted to push you... Thanks for your tips!
