[ANNOUNCE]node-red-contrib-xterm : second beta (sidebar)

[BartButenaers]

@nodecentral

One feature I am looking for is the ability to ssh onto another device on my network and run commands on that, could xterm do that ?

Nope that is currently not possible.
Currently this sidebar ensures that there is only a single config node available under the hood, where all the settings (from the 'Settings' tabsheet) are stored:

In your proposal you would need to have a config node per IP address. And then in the "Terminal" tabsheet, there should be a dropdown on top where you can add/select/remove config nodes. And then - when the "Start" button is pressed - it should connect to the selected IP address. But it now works closely together with my http admin endpoint. And you won't have that endpoint on other servers, unless Node-RED and my node would be installed there. Otherwise my node should be designed to communicate in another way...

But even if that all would be redesigned, then it sounds to me more like distributed Node-RED editor related stuff...

So that is why it is currently not possible, and it will probably never be redesigned...

[knolleary]

@BartButenaers

QUESTION: By talking about security, I am now wondering if my httpAdmin endpoint is secured enough :

RED.httpAdmin.get('/xterm_shell/:terminal_id/:command/:info', function(req, res) {

Or should I do something special for permissions , to avoid that everybody can call the endpoint?

That endpoint has absolutely no security applied to it. Anyone can access it regardless of how they have configured adminAuth.

You need to add the needsPermission middleware with a write permission if it should only be accessed by users with full write access.

[zenofmud]

@BartButenaers

Nope that is currently not possible.
Currently this sidebar ensures that there is only a single config node available under the hood, where all the settings (from the ' Settings ' tabsheet) are stored:

Ummm, I just did it. Runing NR on my mac, opened the terminal in NR and ssh'd into one of my pi's

[BartButenaers]

@greenembrace

The only thought I have about all users is that each command has a unique PID and all sub process of that command are linked to this. Therefore each user would generate there own unique PID which could be filtered.

Had been thinking about something similar, but not sure whether it will be useful.
Each sidebar tabsheet has its own unique terminal id, which I use to make sure that the (input and output) data is communicated between each terminal window and the corresponding pseudo terminal process correctly. The server stores the routing information in a map:

Suppose I implemented the following changes:

• add an output to the Terminal-Input node
• include the PID and/or the terminal Id in the output messages
• show the PID and terminalId (both readonly) in the sidebar.

But then you still need to copy/past the PID and/or the terminal Id in your switch node and deploy your flow to filter your own messages:

But then *other users won't see their own messages anymore. Therefore I'm still not convinced that this is very useful in a multi-user environment. But perhaps I'm completely wrong ... And perhaps I could add it for single-user environments? Because most of the users are using it for small systems ...

@knolleary

You need to add the needsPermission middleware with a write permission if it should only be accessed by users with full write access.

Ok thanks Nick! Was not sure whether that was enough to secure an endpoint ...
The version on Github now contains this:

RED.httpAdmin.get('/xterm_shell/:terminal_id/:command/:info', RED.auth.needsPermission('xterm.write'), function(req, res) {

And now it still seems to be working on my Raspberry.

@zenofmud

Ummm, I just did it. Runing NR on my mac, opened the terminal in NR and ssh'd into one of my pi's

Ah ok. That way. Might be indeed handy. Can you post some more details, then I add it afterwards on my readme page. Thanks !!

[zenofmud]

1. add a xterm_ln node and add ssh details - in my case I used ssh pi@yellowpi.local
2. added another xterm_ln node with `ls'
3. start the xterm running and I see:
   
   
4. Press the 'ssh' xterm and see :
   
   
5. enter the password in the xterm window:
   
   
6. press the 'ls' xterm and get:
   
   

Just for the heck of it, I then SSH back to my Mac and got in with no problem!

[TotallyInformation]

@BartButenaers

Should this be like this or something else?

Yes. The permissions are sort of documented here though not with any detail. With the example you give, an adminAuth authenticated user with the permissions "read" would, I believe, have access as they would if you gave them permissions containing "xterm.read". Since "read" was one of the original simple permissions, you could give a more specific permission such as 'xterm.write' (write was not one of the earlier simplistic permissions and so less likely to be accidentally assumed).

@BartButenaers

But digging into that further is unfortunately at the moment not possible in my limited spare time.

I don't blame you. I've been looking into these things on and off for several years now and I still don't believe that I understand them properly!! The perils of not being a full-time developer perhaps.

In regard to Node-RED websocket security. I'd forgotten about the setting webSocketNodeVerifyClient so I started some testing on that since I can't find any useful documentation.

Unfortunately, I've not yet managed to get that function to trigger at all - perhaps someone else can shed some light? Here is the relevant section of my settings.js file:

    // The following property can be used to verify websocket connection attempts.
    // This allows, for example, the HTTP request headers to be checked to ensure
    // they include valid authentication information.
    webSocketNodeVerifyClient: function(info) {
        console.log('WEBSOKCETNODEVERIFYCLIENT: ', info)

        // 'info' has three properties:
        //   - origin : the value in the Origin header
        //   - req : the HTTP request
        //   - secure : true if req.connection.authorized or req.connection.encrypted is set
        //
        // The function should return true if the connection should be accepted, false otherwise.

        return true
    },

[BartButenaers]

@ghayne, @cymplecy,

@zenofmud just reported to me that he gets a popup, the first time he clicks the "Start" button:

Which is not what I had expected. Do you guys also get that popup or not?

[ghayne]

No popup.

[cymplecy]

@BartButenaers

npm install bartbutenaers/node-red-contrib-xterm

Just installed it and yep

Fine the second time I launched it (as usual)

[afelix]

I’m noticing a difference. In the screenshots with the message there were undeployed changes. The one Garry showed hadn’t. Could that be the difference? Worth testing out. I know that message, I’ve seen it when doing things like closing the tab or going to another web address with undeployed changes. Is the document.location modified anywhere by chance?

[Paul-Reed]

I'm sort of seeing something similar... in that it only starts at the second attempt.
At the first attempt, the node-RED screen appears to refresh, and the sidebar returns to 'info'.
Attempt number 2 means pressing the start button again.
There doesn't seem to be anything reported in the NR log, or browser tools.

However, I wasn't sure if it was your most current node version, so I npm uninstalled it, and again installed it (to ensure I'd got the latest), but after a restart, I couldn't get node-RED to load in my browser, just the continual loading gif. There was no errors in the NR log, and yes I did clear my cache & tried incognito.
I've again uninstalled the node & NR has started normally again, but I haven't got chance tonight to look into it further.

Attached: youtube video

[zenofmud]

This is all done in a empty flow - i.e. there are no nodes added to it.

If you install the node (cli) and start NR then start Xterm, you get the Popup AND deploy goes RED. If you deploy, a configuration node is created and if you stop/start NR then start xterm, the popup does not show up.

If you go to "Manage Palette" you can not remove the node because it is 'in use' because of the configuration node.

If you delete the configuration node, stop/start NR the popup will show up again.

If you don't delete the configuration node and exit NR and remove the node (cli) then start NR again you will see a NR warning:

and in the log you will see:

4 Jan 20:19:35 - [info] Waiting for missing types to be registered:
4 Jan 20:19:35 - [info]  - xterm_config

(remember that configuration node??)

And if you go to the 'Configuration nodes' tab, you will see an orphaned xterm_config node.

[Paul-Reed]

@zenofmud

If you don't delete the configuration node and exit NR and remove the node (cli) then start NR again you will see a NR warning

Yes Paul, I got the same, and also had to delete the node config myself.

[BartButenaers]

Thanks for all feedback!!!
Well I think that is normal behaviour. There should always be 1 config node, where I have store the terminal settings. For every action, the sidebar panel will check whether the config node is available:

1. When 1 config node available, that will be used.
2. When 0 config nodes available, then one will be created.
3. When >1 config node available, then the others will be deleted.

So a lot is going on behind the scenes. But due to those changes, the 'Deploy' button will become active...

Just found out that in Firefox I can reproduce part of those problems: my tabsheets close. So that is at least a point to start my search. Will come back here when I have more news, or more questions ...

[Paul-Reed]

@BartButenaers

Just found out that in Firefox I can reproduce part of those problems: my tabsheets close

I'm using google chrome browser.

@BartButenaers

Well I think that is normal behaviour

It doesn't seem normal to me. Usually when you have an orphaned config node, you get a message saying so. This produces a Flows stopped due to missing node types message.

[BartButenaers]

@Paul-Reed

I'm using google chrome browser.

Yes, me too but that works fine here ...

[BartButenaers]

@Paul-Reed

It doesn't seem normal to me. Usually when you have an orphaned config node, you get a message saying so. This produces a Flows stopped due to missing node types message.

Well I might have misunderstood the concept of the sidebar panels, since this is an undocumented API. But if you look at the code of the few existing side panel repositories, you will notice something like this:

globalTerminalConfigNode = {
    ...
    hasUsers: false, 
    users: [],
    ...
}

I have interpreted like this: since this config node is dynamically created and only used in this sidebar (which isn't a node!!!!), the config node is in fact "unused". But since we don't want it to appear "unused" in the "config nodes" panel, we need to set hasUsers to false (see node-red/CHANGELOG.md at master · node-red/node-red · GitHub). Otherwise it would be removed automatically when a user removes all unused nodes.

So I 'think' you cannot simply compare the behaviour to the config nodes of normal nodes...

[Paul-Reed]

@zenofmud, Paul, after uninstalling the node (& config), did you manage to re-install it successfully again from the latest git?

[ghayne]

@afelix Just checked this, you are right, if I change a flow and do not deploy but click on the terminal tab I also get a popup.

[zenofmud]

Yes I can remove and reinstall it at will