[rust-server] Restrict from_headers matches to the intended auth scheme

[twistali]

Fixes #24095

Problem

The rust-server context.mustache template emits one block per security scheme, each doing an early return on match. The Authorization-header blocks call swagger::auth::from_headers(headers) and bind the result unconditionally:

if let Some(auth) = swagger::auth::from_headers(headers) {
    let context = context.push(Some(auth));
    return self.inner.call((request, context))
}

Since swagger-rs 7, from_headers is no longer scheme-typed. It returns Option<AuthData> and matches either scheme (swagger-7.0.1 src/auth.rs:216):

if value_str.to_lowercase().starts_with("basic ") { /* AuthData::Basic */ }
else if value_str.to_lowercase().starts_with("bearer ") { /* AuthData::Bearer */ }

So a Basic-only block swallows Bearer requests (and vice versa) and returns immediately, making every later security scheme block unreachable — including in-header apiKey blocks.

Impact: for any spec where an Authorization-header scheme precedes an in-header apiKey scheme, a request carrying Authorization: Bearer … is authorized via the wrong scheme and the API key / client certificate is never evaluated. Where the mismatched path has a permissive fallback (e.g. AllowAllAuthenticator when OAuth is unconfigured) this is a silent authorization bypass. This is a regression from the swagger 5/6 typed from_headers::<Basic>(headers) form.

Fix

Option B from the bug ticket — restrict each block's pattern to the variant it was generated for, so a non-matching header falls through to the next block instead of being consumed:

// isBasicBasic
if let Some(auth @ AuthData::Basic(..)) = swagger::auth::from_headers(headers) { … }

// isBasicBearer, isOAuth
if let Some(bearer @ AuthData::Bearer(..)) = swagger::auth::from_headers(headers) { … }

AuthData is already imported by the template, so no new imports are needed, and no change to swagger-rs is required — this fixes every 7.x consumer immediately.

Note this fixes isOAuth and isBasicBearer as well as the reported isBasicBasic: a Basic header could equally be swallowed by a Bearer/OAuth block.

Behaviour change

Worth calling out explicitly: on an API declaring only Basic auth, a request with Authorization: Bearer … previously reached the authenticator as AuthData::Bearer; it now falls through to context.push(None::<AuthData>) and is treated as unauthenticated (and symmetrically for a Basic header on a Bearer/OAuth-only API). That is the intended security fix, but it is a semantic change for anyone relying on the permissive behaviour. Happy to retarget if maintainers consider this breaking.

Not addressed (pre-existing, out of scope): an in-header apiKey scheme whose header name is literally Authorization would still collide.

Changes

• modules/openapi-generator/src/main/resources/rust-server/context.mustache — scheme-restricted patterns for the isBasicBasic, isBasicBearer and isOAuth blocks.
• RustServerCodegenTest.testAuthSchemeBlocksOnlyMatchTheirOwnScheme — new regression test asserting both the correct forms and, via assertFileNotContains, the absence of the unrestricted forms; also asserts the in-header apiKey block is still generated.
• Regenerated samples: openapi-v3, petstore-with-fake-endpoints-models-for-testing, ping-bearer-auth.

Testing

• ./mvnw clean package — BUILD SUCCESS, full test suite green.
• ./bin/generate-samples.sh bin/configs/rust-server*.yaml — 7/7 generators succeeded, no sample drift.
• mvn -pl modules/openapi-generator -am test -Dtest=RustServerCodegenTest — 7/7 pass.
• Confirmed the new test is not vacuous: reverting context.mustache alone makes it fail with does not contain line [if let Some(bearer @ AuthData::Bearer(..)) = …].
• cargo check --all-features on the regenerated petstore-with-fake-endpoints-models-for-testing sample compiles clean.
• Verified no rust-server sample retains an unrestricted = swagger::auth::from_headers(headers), and that context.mustache is the only template referencing from_headers.

CC @frol @farcaller @richardwhiuk @paladinzh @jacob-pro @dsteeley

PR checklist

• Read the contribution guidelines.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

---

Summary by cubic

Restricts rust-server auth handling to match only the intended scheme (Basic vs Bearer) so cross-scheme matches no longer short-circuit later auth blocks like header apiKey (fixes #24095).

• Bug Fixes

  • Generate scheme-restricted matches in context.mustache: AuthData::Basic(..) for Basic and AuthData::Bearer(..) for Bearer/OAuth.
  • Prevent Basic/Bearer blocks from consuming the other scheme; preserves reachability of in-header apiKey.
  • Add regression test to assert restricted patterns; regenerate Rust server samples.

• Migration

  • Wrong-scheme Authorization headers on single-scheme APIs now fall through as unauthenticated.
  • No consumer changes needed; applies to all swagger-rs 7.x generated servers.

^{Written for commit ddd272f. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 5 files

_{Re-trigger cubic}

[dsteeley]

This fixes the issue here, but the untyped from_headers still seems like a footgun for anyone hand-rolling swagger-rs 7.x. Worth an issue against Metaswitch/swagger-rs too?

[dsteeley]

@wing328 circle CI looks unrelated. Are there issues occurring on that CI system?

[dsteeley]

Two potential testing gaps to consider. There's no fixture proving Basic+Bearer coexist without swallowing each other (only OAuth+Basic is tested), and the assertions are string-exact rather than runtime tested.

A request-level test through AddContext::call would prove the actual fallthrough behavior as cargo test on the generated samples is run in the GitHub workflow.

[wing328]

for circleci failures, please ignore those for the time being