I want to open a VNC viewer exe from the Ignition perspective client.
The gateway for this specific project is on Linux-based system, The perspective clients will be launched on Windows-based systems (most of the times)
I have tried the system.util.execute and system.net.openURL function too - I guess these functions does not support in perspective.
The closest thing [1] would be a custom application (that your users have to install/you install for them) on each client computer that registers as a protocol handler and parses the provided URL to open some native executable:
Like Paul mentioned, you kind of can and we do this quite a bit. We have an in-house website for managing all of our HMI’s and users across multiple facilities so you can just lookup a machine and there is a VNC button that links to a URL similar to this <custom_program>:?<our_vnc_viewer>.exe%20-connect%<device_ip>:<device_port>%20-<user_password>
so then when you click the VNC button, it either opens or if it doesn’t work it gives you instructions on how to install custom_program on your computer.
This is incredibly nice because then when we rotate passwords or update the IP of an HMI we can store that in some database and automatically update our internal tool.
You will need to build your own custom_program but this is certainly doable
What? You embed arbitrary executable names into URLs? Oy!
On closer inspection, it encodes an arbitrary command line into the URL. That's not just scary, but an invitation to bad guys to abuse your employer. Aauuuugh! That's in your profile!
"Incredibly nice" is no excuse for a severity 10 security hole.
I'd make it so the custom executable receives an alias, and the aliases are mapped to certain executables, with unknown aliases being ignored. And then still make it prompt the user with the executable before actually executing it.
The command and arguments are all hard coded, I just used <our_vnc_viewer> and the other stuff in <> as placeholders for actual values. So at no point can you input any value that influences the command that is executed.
If things are hard-coded, you shouldn't need to include privileged info in the URL. Just a URL like custom-proto-handler://some-named-target. I would not include a target's password in either URL or hard-coded config.
I would agree and this could easily be moved into the custom-proto-handler. I believe the reason it wasn’t is because this internal tool is only accessible to certain people to change the IP’s and passwords of devices but this custom-proto-handler is used in some other places so we didn’t want to bundle in any database integration for pulling in VNC passwords.
This tool is also only accessible on an internal network and doesn’t make any calls outside of the network which is why the password in the URL was allowed
Some VNC servers include a listener on port 5800 which will serve a HTML page offering a link to download a Java-based VNC viewer into the browser. This will then connect as normal via port 5900.
Try it out in the client browser. If that works then try embedding it in a Perspective Inline Frame component. (I haven't tested it so I don't know where this scheme might come unstuck.)
For remote viewing-only mode you shouldn't need username / password. This should be configurable on the VNC server.
There’s a resource on the Ignition Exchange that uses NoVNC and the WebDev module in Ignition to do a web based VNC client. I’ve personally modified it to work with some additional changes/features:
This has been field tested now and works very well.