I need to get the IP addresses from the Perspective Sessions. Any ideas as I don't find anything in the forum

host session property: Session Properties - Ignition User Manual 8.1 - Ignition Documentation

And for all sessions, try system.perspective.getSessionInfo - Ignition User Manual 8.1 - Ignition Documentation

Why didn't I think of that. Trying to extract IP addresses and Users from Windows has been so much fun I didn't think of the obvious in this case. Thanks Kevin.

Do note that if a client is behind a NAT router, you will only get the IP of the router. And there is no help for that. (And none possible, at least for browsers.)

Fortunately I don't have that issue. Just a plant network I am trying to get the PC IP's for which is now working.

1 Like

So a new problem: I have several plants, each with their own gateways. I am using the meta:visible item to control when a button is seen based on the PC IP address that Perspective is being used on. It works wonderfully in all but one plant. No matter what I do if I put conditions on the meta:visible item in one of the plants it disappears regardless of IP. All props are identical and the project is inherited from a global source at the corporate site.

This sounds more like that IP value is just never meeting the requirements you've set for visibility. Do you have insight into what the value is, and have you investigated why it's never meeting your criteria?

Yes the value qualifies and I have it visible for my use and verification.

It also works on that gateways designer. Project properties are also the same as other sites. I am thinking something in the gateway but haven't found anything yet.

Perspective seems to think it does not. Are you examining the IP within Perspective, or did you obtain the IP from the computer? Load balancers and network firewalls wreak havoc between local workstations and gateways. If you're able to message me the value you're encountering and the display conditions I'll try to look at what's happening.

I have a popup that contains low level details from session props that I use to diagnose issues like this. Maybe create something to show the session props in the client and check these are what you're expecting to see?

I am using session.props.host to get the IP. I also display it in a label field on one of the pages for verification which is working at the plant and showing each PC's IP like it should. The same code works at the other plants.

Without supplying the code and value here you'll need to contact support.

For the button:

And the custom property in session props:

And again this works in all other plants. I have used .host and as seen here .address.

But I still need to know the offending value as the session believes it to be, AND I need to know what "10." + {[SITE_BOF]Site Number} equates to for the session.

By the way, this could all be avoided by using Security Levels via Security Zones.

1 Like

We do not use logins for the operators who can use this button. We use a corporate AD account tied to SAP. I am keeping external people who can also access this application from using the button when they shouldn't be. The line computers autologin with windows but perspective can't pull this info and they have no logins. The only way I can isolate is to use a distinct IP that is unique to each plant and is tied to a site tag. All plant IP's begin with 10.XXX with XXX being the plant number.

If you know of a way to take a corporate AD account and tie it to a security level please enlighten me as I do not now how to do that since I have never had to do it before.

How does this ever work at all? How can left({this.props.address}, 6) = 10. ever be true?

edit: nevermind, it's equaling the concatenation of 10. + whatever. Or apparently it's not in this case.

I am taking the first 6 of the IP and then comparing to everything on the other side of the equals. Again it works in all other plants.

Throw up labels that show us the value of props.address and the site number so we're not just blindly believing it. Another label that shows an expression concatenating the 2 might be interesting, in case there's some weird numeric casting at play.