Celebrating the 22th anniversary of the UltraVNC: https://forum.uvnc.com/viewtopic.php?t=38031
Update: UltraVNC 1.4.3.6 and UltraVNC SC 1.4.3.6: https://forum.uvnc.com/viewtopic.php?t=37885
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864

Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Bluesky/AT Protocol: https://bsky.app/profile/ultravnc.bsky.social
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc

restricted keyboard from viewer (password option)

Any features you would like to see in UltraVNC? Propose it here
Post Reply
chambers.jr
Posts: 1
Joined: 2012-01-03 08:41

restricted keyboard from viewer (password option)

Post by chambers.jr »

In addition to "full control" and "view-only" passwords we would like a third password ( "view-plus" ??) that allows ONLY left-mouse clicks and "non-control" keystrokes (alpanumeric + punctuation). The viewer client would not have to change but the server could "throw away" unsupported keystrokes based on the password. Our main application is to run vnc at an unattended kiosk, where the kiosk user may use our voip-phone to contact a call center attendant for support. The call center attendant would use the java viewer to connect to the kiosk and "help" the kiosk user enter data into the available onscreen applications, but the call center operator would not be able to do anything the kiosk user couldn't do e.g. invoke windows functions (like control-<x>, alt<x>, ctl-alt<x>, etc.). In general only those characters that are traditionally available at a specialized kiosk keyboard. (ctl-x and ctl-c and ctl-v would be OK - these are usually provided by dedicated keys on a "kiosk" keyboard). A future implementation could provide a table-driven approach where the administrator could provide multiple "allowed keystroke tables" to be defined, but we do not require this. We would be willing to sponsor this development if the price and timeline were reasonable.
Post Reply