mirror of
https://github.com/sol1/rustguac.git
synced 2026-09-10 09:35:45 +00:00
Dave Kempe
3a37cb39d9
Closes #132. VDI containers come in two patterns: ones whose entrypoint reads VDI_USERNAME / VDI_PASSWORD env vars and provisions an account matching them (the contrib/vdi-test-image style), and ones with a baked-in fixed account that ignore those env vars. Pre-change, only the first worked; users with baked-image containers had to log in manually inside the session because rustguac's auto-derived RDP credentials never matched the container's actual account. - AddressBookEntry gains optional container_username and container_password fields, persisted to Vault. - When set, session.rs uses those values for the RDP connect into the container instead of deriving the username from the operator's identity and generating a per-connect password. - VDI_USERNAME / VDI_PASSWORD env vars are still injected with the resolved values - images that read them get consistent state; images that ignore them keep using their baked-in account. - The container name derives from the resolved username, so an entry with a fixed container_username produces a container shared by all operators connecting through that entry. Documented. - EntryInfo exposes container_username back to the editor; container_password is never serialised to clients (has_container_password boolean indicates whether one is stored). - The entry update handler preserves container_password when not supplied on update (same pattern as password / private_key). - Both fields go through entry_credential_variables and resolve_credential_variables, so the actual values can be sourced from each operator's saved credential variables ($corp_username etc). - Connections UI gains the two fields with explanatory text linking out to the VDI docs and credential variables docs. - docs/vdi.md restructured around the two patterns (Pattern A: env-var driven, Pattern B: baked-in account) with the container-sharing note for Pattern B. - docs/credential-variables.md gains an explicit "where variables can be used" table covering the new fields. Subtle side fix: env merge in session.rs used to call env.entry(K).or_insert(V), which meant a user-supplied VDI_USERNAME in container_env would silently win over the auto-derived one - opposite of the documented intent ("Don't let user-provided env override the core VDI vars"). Switched to env.insert() so the resolved values always win.
