Yamcs action: support HTTP Basic authentication for servers behind an authenticating reverse proxy

[paullizer]

Summary

Add optional HTTP Basic authentication to the Yamcs action so SimpleChat can reach a Yamcs server that is published through a reverse proxy enforcing HTTP Basic authentication.

User Value

A partner team's Yamcs dev server, which runs their simulation environment, sits behind an Apache reverse proxy that challenges every request with HTTP Basic authentication backed by Active Directory. Operators sign in with a directory username and a temporary password. Once past the proxy, Yamcs itself has no authentication enabled.

The Yamcs action can authenticate to Yamcs, but it had no way to answer a front-door proxy challenge, so that server was unreachable even when every Yamcs setting was correct. The same topology is expected on the mission server, so this also unblocks that path.

Proxy authentication must stay optional: a Yamcs simulator running locally has no proxy and must not send an unnecessary credential.

Proposed Behavior

A Reverse Proxy Authentication toggle on the Yamcs action. When enabled, the action sends an HTTP Basic Authorization header on every request, which the proxy consumes before Yamcs sees it. Off by default.

Credentials can be entered inline on the action, with the password stored in Key Vault, or supplied by a reusable username and password identity. Because the directory issues temporary passwords, the identity path matters: the credential is rotated once under Workspace → Identities and every referencing action picks it up without being edited. The proxy credential gets its own identity reference, separate from the Yamcs credential, so one action can use both.

Compatibility with Yamcs authentication methods

Only one Authorization header can be sent, which makes some combinations impossible rather than merely unimplemented:

Yamcs authentication method	Allowed	Reason
No Authentication	Yes	Yamcs sends nothing, so the header is free for the proxy. This is the dev-server case.
API Key	Yes	The Yamcs API key uses x-api-key, leaving Authorization for the proxy.
Username and Password	No	Yamcs exchanges credentials for a bearer token on Authorization, and the /auth/token request would itself be refused by the proxy.
Access Token	No	The bearer token also needs Authorization.

Blocked combinations are reported at save time and by Test Yamcs Connection rather than failing later during an agent turn.

Acceptance Criteria

• A Yamcs action can connect to an unauthenticated Yamcs server behind a Basic-auth proxy
• The toggle is off by default, so a directly reachable Yamcs server is unaffected
• Proxy credentials can come from a reusable username/password identity, distinct from the Yamcs credential reference
• The proxy password is stored in Key Vault and never returned to the browser
• Incompatible authentication combinations are rejected at save time, by the health checker, by the test-connection route, and in the action modal
• Test Yamcs Connection exercises the proxy credential and distinguishes a proxy rejection from a Yamcs rejection
• Functional test coverage
• Action reference, feature documentation, and release notes updated

Notes

yamcs-client==2.1.0, already pinned in requirements.txt, ships BasicAuthCredentials, so no dependency change is needed. It is imported separately from the other credential classes so a deployment on an older client keeps working for every non-proxy method.

Known limitation: an identity resolves within the workspace scope that owns the action, so a shared group action resolves one group-scoped credential. Per-user credentials on a single shared action would require runtime per-user credential resolution and is not in scope here.

Implemented in version 0.261.010.

[paullizer]

Implementation is complete and open for review in #1447 (targeting Development).

Version: 0.261.012. The branch was rebased onto Development after 0.261.010 and 0.261.011 shipped for the Azure Managed Redis work, so the version and release-notes section were re-numbered to avoid colliding with those releases.

Validation:

• New functional_tests/test_yamcs_basic_auth.py — 12/12
• Existing test_yamcs_action_plugin.py — 14/14, no regression
• Docs coverage 7/7, docs quality 6/6, route policy suites pass
• Wider sweep across identity, plugin, health-check and Key Vault suites: zero new failures

Notes from review: a code review pass caught one real bug, now fixed — turning the toggle off blanked the stored credential, which would have dropped the Key Vault reference and orphaned the secret. A regression test covers it. Separately, BasicAuthCredentials is imported lazily so an older yamcs-client keeps working for every non-proxy auth method.

Follow-ups, not blocking:

• A Latest Feature card still needs screenshots of the new Reverse Proxy Authentication panel from a running instance.
• Live connectivity against a real proxied Yamcs server has not been exercised; that needs the partner team's dev environment.
• A shared group action resolves one group-scoped proxy credential rather than a distinct credential per member. Per-user resolution at chat time would be a materially larger feature and is out of scope here.