No..... I want the client to connect to node red then I want the node red server to interrogate the client, or the node red server must trigger a client side interrogation, to determine the network parameters as set up on the client for further processing....
What is the point in that, when you already know the ip from the message emitted by the ui_control node?
The point is, I want to know....
The mechanics of client side interrogation can be utilised in many other procedures besides network parameters for determining local machine conditions and status which I could implement throughout my network...
Can you give an example of exactly what you want to do please, other than ip address, so that I can better understand the requirement?
At this stage, lets just stick to ip address, its a simple enough question....
As, I think, already mentioned, uibuilder already does all of this for you if you don't need to rely on the rest of Dashboard's facilities.
Hi Julian,
Sorry, didnt reply to your previous post....
Noted re uibuilder, I just know pretty much nothing about it.... I will get into it when I get a chance...
Regds
Ed
The reason I wanted another example is that there is a very limited set of information that is knowable inside the browser. You mentioned machine condition and status, are those accessible from within the browser?
In a ui_template node you can provide a script to the client which can run any javascript code you want and send the results back to node-red. If you can find a way, in the browser, of determining what the ip address of the connection to node red is then you can send it to node red. I don't know whether that is possible. As I said earlier you may have multiple network connections in the device, each with its own ip address, I don't know whether it is possible to (in the browser) to determine which one is being used to connect to node-red. The ip address is added into the comms by the network layers I expect.
That is correct, JavaScript in the browser cannot obtain the IP address. To do that, you have to use a web worker I think.
However, both ExpressJS and Socket.IO servers DO have access to the client's IP address. Here, for example is the uibuilder code that finds the client real address from the Socket.IO connection:
function getClientRealIpAddress(socket) {
let clientRealIpAddress
if ( 'headers' in socket.request && 'x-real-ip' in socket.request.headers) {
// get ip from behind a nginx proxy or proxy using nginx's 'x-real-ip header
clientRealIpAddress = socket.request.headers['x-real-ip']
} else if ( 'headers' in socket.request && 'x-forwarded-for' in socket.request.headers) {
// else get ip from behind a general proxy
if (socket.request.headers['x-forwarded-for'] === undefined) throw new Error('socket.request.headers["x-forwarded-for"] is undefined')
if (!Array.isArray(socket.request.headers['x-forwarded-for'])) socket.request.headers['x-forwarded-for'] = [socket.request.headers['x-forwarded-for']]
clientRealIpAddress = socket.request.headers['x-forwarded-for'][0].split(',').shift()
} else if ( 'connection' in socket.request && 'remoteAddress' in socket.request.connection ) {
// else get ip from socket.request that returns the reference to the request that originated the underlying engine.io Client
clientRealIpAddress = socket.request.connection.remoteAddress
} else {
// else get ip from socket.handshake that is a object that contains handshake details
clientRealIpAddress = socket.handshake.address
}
// socket.client.conn.remoteAddress
// Switch to this code when node.js v14 becomes the baseline version
// const clientRealIpAddress =
// //get ip from behind a nginx proxy or proxy using nginx's 'x-real-ip header
// socket.request?.headers['x-real-ip']
// //get ip from behind a general proxy
// || socket.request?.headers['x-forwarded-for']?.split(',').shift() //if more thatn one x-fowared-for the left-most is the original client. Others after are successive proxys that passed the request adding to the IP addres list all the way back to the first proxy.
// //get ip from socket.request that returns the reference to the request that originated the underlying engine.io Client
// || socket.request?.connection?.remoteAddress
// // get ip from socket.handshake that is a object that contains handshake details
// || socket.handshake?.address
return clientRealIpAddress
} // --- End of getClientRealIpAddress --- //
You will note that you have to take into account any proxies that sit in the way as well.
Ok....Interesting times....
What about a different angle on it? How could/is it possible for, the server to trigger a command that will run locally on the client? ie, netstat or something similar....(Obviously client software and client permission dependent..)
Regds
Ed
I don't think that is possible without installing additional software on the client. It is a good thing it is not generally possible. You would not want a website you visited to be able to execute arbitrary code on your PC.
Good or not, it is something I have a need for.... As per client side, are you aware of anything software wize?
You could run another instance of node-red (in the client) and communicate with the original one using MQTT or http, for example. Then in the NR running in the client you can do what you want using Exec nodes if appropriate.
Alternatively have a look as SNMP which is designed for exactly this sort of purpose, monitoring devices on a network.
We seem to be getting a long way from your original requirement, which was to switch to a particular tab in the dashboard when a client connects.
Far from an ideal solution, any utility to be installed must be tiny, if required, and preferably part of the client OS by default...
Also far from ideal for me....
No, the original requirement is IP local address...See my first post... Using it to switch tabs is but a current convenience relating to local IP address... The tab switching is largely sorted, but I still haven't seen a solution that I am capable of using, to do a local interrogation on demand triggered by the server...
Here is one option.
Run a python program on the client that subscribes to MQTT on a particular topic. when it receives a message it published its name and the IP address. In NR, the ui-control triggers a publication of the ip request and an mqtt-in node gets the results for you to use,
I think that would work under most modern systems quite well, unfortunately the hardware I am utilizing is quite varied (read that as ancient) and as such would probably be "problematic"...
In that case use whatever language does work on the problematic systems.
You still have the problem of knowing which of the network interfaces (if more than one) is being used by the browser.
Sifting through the network interfaces..... Well I have to be able to scan them first...
To be able to do a hardware interrogation client-locally on demand opens up a whole range of possibilities for me on my network....
You don't actually need the IP address, you need to know which machine it is?
I definitely do not know what I'm talking about here but could you use canvas fingerprinting? Google seems to be able to tell what machine I'm on.
Are you sure you want a "local" address? From the client's perspective, that might always be localhost.
You want the LAN address I assume? If so, you must either have something independent of the browser running that captures the LAN address to a location that the browser is permitted to pick it up from. A hard problem since browsers are specifically prevented from doing cross-domain tasks. Or you must run your service via a proxy on the LAN that will see the traffic from the client and add suitable http headers that the Node-RED server can pick up.
As already stated quite clearly, if your Node-RED server is running on the same LAN as the client, then the ExpressJS and Socket.IO servers in Node-RED will have access to the client's address. If the server is on a different LAN (e.g across the Internet), then only the Internet address of the client will be accessible unless you have a LAN proxy.
These are not node-red issues, this is the way that TCP/IP and HTTP networking operates.