[schmitch]

Fixes #756

What changed

A credential-forwarding realm with accept_client_passwords: false was dropped from the clients' password chain (HTTP Basic on the feeds and /v2/token, npm login --auth-type=legacy). Its users' passwords therefore went on to the upstream of a credential-forwarding realm after it. The sign-in was still refused, but the password had already reached a server that was not the user's realm's.

• ForwardingRealmGuard (new, crates/core/src/auth/realm_guard.rs): takes the closed realm's place in the client chain. It asks no upstream. For a name the realm owns (find_upstream_user(username, Some(realm_id)), active or not) it returns AuthOutcome::NotAccepted. Any other name gets Skip, and a failed lookup gets Failed, so the password is not forwarded on a database error either.
• Chain: AuthOutcome::NotAccepted now ends the chain whatever provider returns it. Before, only a Local provider's did; it was introduced in Client passwords: a closed local realm's refusal no longer counts towards the login lockout #845 for the local realm's reject-only guard. The outcome stays ChainOutcome::NotAccepted: the same 401 as a wrong password, and not counted towards the sign-in lockout, since nothing was checked.
• RealmCache::build (crates/server/src/auth/realms.rs): the client chain keeps every credential-forwarding realm in its place. An accepting realm keeps its provider and a closed one gets its guard. The local provider's forwarding_follows now looks only at providers that actually ask an upstream, so a local realm followed only by guards still pays its dummy hash. The browser-login chain is unchanged.
• Docs: docs/deployment.md (Passwords from clients) gets a bullet for the closed forwarding realm. Doc comments in provider.rs, chain.rs and token.rs are updated.

Tests

• crates/server/tests/client_passwords.rs covers the issue's scenario. Realm order is local, B (corp: forwarding, closed, own mock upstream), then A (nexus: forwarding, accepting).
  • a_closed_forwarding_realms_passwords_never_reach_the_next_realms_upstream: B's user signs NuGet, raw, docker login and npm login in with B's right password and with a wrong one. Every client gets 401, both passwords get the same answers, and neither A's upstream nor B's receives anything. A's own user still gets past B's guard to A. The browser login still accepts B's password, checked at B's upstream only.
  • a_closed_forwarding_realm_guards_its_deactivated_accounts: the same guard holds for a deactivated B account.
  • Without the fix both tests fail: with the source changes stashed and the tests kept, A's upstream received B's user's password (left: 2, right: 0 and left: 1, right: 0).
• crates/core/src/auth/chain.rs unit test an_upstream_realms_not_accepted_is_terminal_and_never_forwarded: a non-local NotAccepted stops the chain, and the next upstream is never consulted.
• Run locally, all green: cargo fmt --all --check, cargo clippy -p forge-core -p forge-server --all-targets -- -D warnings, cargo test -p forge-core, cargo test -p forge-server --lib plus the admin, auth_realms, auth_settings, client_passwords, credential_kinds, invitations and realm_seed integration tests, and cargo xtask changelog --check.

Changelog

docs/changes/2.2.0/756.security.md (Security): the leak, and that a closed forwarding realm now keeps its accounts' names in the clients' chain.

Notes

• The guard only knows accounts the realm has already created. A B user who has never signed in has no account, so their client password still goes on to the next realm. Forge cannot tell that name is B's without asking B's upstream, which a closed realm must not do. The deployment docs say so.

Not fixed here

• A credential-forwarding realm that fails to build is left out of both chains, with no guard. Examples are undecryptable secrets or a URL that no longer passes the https rule. Its users' passwords, from the browser login too, then go on to the next forwarding realm's upstream. The code comment says "its own logins fail (closed)", but they are forwarded instead. It affects accepting realms as well, not only closed ones.
• docs/deployment.md is stale after Client passwords: a local realm that accepts none counts each refused client password as a failed sign-in, so a user's old client locks them out of the browser login #795. It still says a closed local realm's refused client password counts towards the lockout ("the lockout counts it"). Since Client passwords: a closed local realm's refusal no longer counts towards the login lockout #845 it does not.

---

Generated by Claude Code