Determine LOCAL IP address

General
41

Perhaps I am missing something - but couldn't you detect the client based on a parameter ?
ie.
client1 uses url http://ip:1880/ui/#!/0?client=client1
client2 uses url http://ip:1880/ui/#!/0?client=client2

These params can be read from the ui-control node.
Then again, the url could point to the preferred tab directly too.

42

(only because this seems to not be resolving itself)

A while ago I looked at the thread and left as too many cooks.... etc.

But now it has reached 40+ posts.... It seems maybe I should post something I read in the first few posts.

I think there is confusion about getting to particular GUI pages of Node-red and how to get to them directly from a remote machine.

Because you can't say:
ip.address:/1880/ui/page_name
Where page_name is the name the GUI shown in Node-Red.

I suspect this is the point of contention.
(But: I've been wrong before - as a lot of the other locals can attest.)

43

Hi Julian,

Thanks for the info!!

Yep 100% sure - Now this is going to put the cat in the hen house - Although IP address is probably the most commonly occurring "parameter" on any networked machine - it is not what I am ultimately after - There is other data that I would like to draw from specific clients should it be possible - No, for all of those watching the thread, I will NOT specify at this stage what this data is, for fear of the thread being dragged off course....

Suffice it to say, that should it be possible to trigger for the server a local command on the client, I am EXTREMELY interested in its limitations, the level of commands that can be accessed, and, most importantly, the methodology of how to do it... Yes, I am fully aware of firewalls, OS differences, command syntax differences, access rights of the user, etc,etc,etc...

No, this is not a viral/hacking howto that I am looking at, enough said about that...

Noted...

Actually, I still do - Not so much for the address, but how to go about it.... See post#1 Line#1

Andrew, See post#1 Line#1 and the clarification used in post#1 Paragraph#2

To all: Referring to post#1 paragraph#3 - Reason - I can see that this has confused a lot of readers into believing that this is the ultimate goal, but it is not... Post#1 Line#1 is the question...

Regds
Ed

44

As long as you got it resolved in the end.

I guess that's all that matters.

45

And the answer is that you cannot do that without installing or using additional s/w on the device. Either something standard like SNMP or something like node-red or a little Python app, for instance.

46

The topic keeps changing - if paragraph 3 is not relevant, then you can use netstat or the ss command to determine the client ip's that are connecting to the :1880 port, eg;

ss -tn src :1880 | grep -i estab | awk '{print $5}'
47

@eddee54455 wants to be able to run a script on the client to determine undisclosed parameters of the client, the apparent IP requirement is has become irrelevant, apparently.

48

Yeh... That about sums it up, but the ip requirement is relevant as a test case at the very least...Succinctly put Colin... So is Node Red capable of triggering a script on a client? (Within browser capabilities of course)

I suspect that your answer would be an immediate "No".... But maybe there is a server side bit of magic that might enable it...

49

That is your limitation. The browser is a sandbox and whatever is available in the api of browser can be requested - if you (read: the server) provides payload that will processes all the requires info. ie. just like google retrieves everything they can with analytics.

1 Like
50

So lets be clear up front - browsers, by design, have VERY limited access to a device, as others have said, anything else would be a security nightmare.

However, there are some ways around some of those limitations - namely by making use of web workers and approved device API's. The API's will give you limited access, for example, to GPS, movement, perhaps device temperature. But many other things cannot be done at least without manual user interaction.

You can further get around some of that by splitting your needs in 2 with a local service sending data to an approved and secured API while the actual user interface happens via normal web pages. In some cases, you could also write specific browser extensions since they have more access to both the client and the web pages.

But to reitterate: The local device is a different DOMAIN to your web server. Cross domain interactions are deliberately limited, especially when one of the domains is the local device.

There are much better data points than IP Addresses (which are easily spoofed/changed and may be changed because of intermediate proxies). But because they are better identifiers, they are blocked to the browser.

In uibuilder, I've managed to add 2 additional identifiers beyond the IP Address (which, by the way, will NOT be the LAN address unless the server is on the same LAN as the client - or at least within a known WAN such as an enterprise WAN, not the Internet).

Firstly, a "stable client identifier" - that is created by the SERVER if the client library didn't pass it in the initial handshake. It is passed to the client which stores it in localstorage if it is allowed to.

Secondly, a tab id - that is an internal browser identifier (with a simple letter prefix). Only guaranteed unique to the browser instance.

If you need to securely identify a client device, you can do so in many ways. The easiest being a device certificate. Of course, that requires some agreed Public Key Infrastructure and a delivery mechanism to get a unique certificate to each device (via some kind of device management tooling). There are other possible ways to achieve it but that would be the most robust as it would be part of your device management processes.

1 Like
51

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.