Repository navigation
Fixes a hang that could make rustguac stop answering for everyone when a target's hostname did not resolve, and adds sharing folders with individual users.
Fix: an unresolvable hostname no longer stops rustguac
Before connecting, rustguac checks the target against its network allowlist, which means resolving the hostname. That lookup blocked one of rustguac's worker threads, and when the DNS server did not answer ("Temporary failure in name resolution") it held it for the resolver's whole retry time, often tens of seconds. A few such connects at once, one person retrying or two people clicking, held every worker thread, and rustguac stopped answering anything, health checks included. Behind a proxy that looked like a 503 for everyone for a minute or so, with no crash and nothing in the log beyond the failed lookup.
Lookups now run without holding a worker thread and give up after 5 seconds. A target whose name does not resolve fails that one connect with "DNS did not answer within 5 seconds", and everyone else carries on. Thanks to Jon Sobels-Craven for the report and for narrowing it down.
If you see that message, the rustguac host cannot resolve the target's name: fix its DNS, or reach those targets through a jump host, which resolves them itself.
Share folders with individual users (#243)
Folders can now be shared with individual users by login email, as well as with OIDC groups. Add them under Allowed users in the folder settings, one per line, or through the API as allowed_users. A user does not need to have logged in first: access is checked when they use rustguac. Because folder settings live in Vault, this applies on every rustguac instance sharing it.
That makes a folder per user straightforward, for example users/jsmith holding a personal VM and shared only with jsmith@example.com. Only admins can see who a folder is shared with. Thanks @3zAlb for the request.
Folders on the way to something shared now appear
If you could open a subfolder but not its parent, the subfolder was unreachable from the Connections tree, because the parent was hidden. The parent is now shown. Opening it says nothing in it is shared with you directly, and you open the subfolder inside. This applies to group access too.
VNC username (#242)
VNC connections can carry a username as well as a password, which VeNCrypt, RealVNC and macOS Screen Sharing need. It is in the connection editor, the connect-time credentials prompt and ad-hoc sessions. Contributed by @jaroslaw-dutka.
Documentation
- The folder access section now covers
allowed_users, and corrects a mistake: a folder with no allowed groups is admin-only. The docs had said every authenticated user could see it. - The Wake-on-LAN and SSH font size fields added in 1.10.2 are now in the API reference.
Upgrade note
Older rustguac versions sharing the same Vault ignore allowed_users, so they show a user-shared folder to admins only. Upgrade all instances that share a Vault together.