Context
Follow-up from review of OpenAPITools/openapi-generator#24607, suggested by David Steele. That PR fixes the generated rust-server code, but the underlying footgun lives here in swagger-rs and affects anyone hand-writing a 7.x service too.
The problem
- swagger-rs 6.x:
from_headers<S: Scheme>(&HeaderMap) -> Option<S> — the scheme was part of the call, so from_headers::<Basic>(..) returned None for a Bearer header.
- swagger-rs 7.x:
from_headers(&HeaderMap) -> Option<AuthData> — matches any Authorization header, Basic, Bearer, or ApiKey.
Auth-check blocks conventionally return early on a match. With the de-typed 7.x API, the natural port of 6.x-style code silently accepts credentials for a scheme it wasn't meant to handle, and makes every later scheme-specific check unreachable. Critically, 6.x code compiles unchanged against 7.x while changing behaviour — no compiler error, no warning, no CHANGELOG note.
Related: OpenAPITools/openapi-generator#24095 (bug report) and #24607 (fix — pattern-matches the AuthData variant at the call site to use the untyped API safely).
Proposed fix
Scheme-typed accessors alongside (or instead of) the untyped one, e.g.:
pub fn basic_from_headers(headers: &HeaderMap) -> Option<(String, String)> { ... }
pub fn bearer_from_headers(headers: &HeaderMap) -> Option<String> { ... }so intent is explicit at the call site, matching 6.x's ergonomics.
Fallback
If a typed API isn't wanted, at minimum a doc comment on from_headers (and a CHANGELOG entry) calling out the 6.x→7.x behaviour change would help — worthwhile on its own even alongside typed accessors.
Context
Follow-up from review of OpenAPITools/openapi-generator#24607, suggested by David Steele. That PR fixes the generated rust-server code, but the underlying footgun lives here in swagger-rs and affects anyone hand-writing a 7.x service too.
The problem
from_headers<S: Scheme>(&HeaderMap) -> Option<S>— the scheme was part of the call, sofrom_headers::<Basic>(..)returnedNonefor a Bearer header.from_headers(&HeaderMap) -> Option<AuthData>— matches any Authorization header, Basic, Bearer, or ApiKey.Auth-check blocks conventionally return early on a match. With the de-typed 7.x API, the natural port of 6.x-style code silently accepts credentials for a scheme it wasn't meant to handle, and makes every later scheme-specific check unreachable. Critically, 6.x code compiles unchanged against 7.x while changing behaviour — no compiler error, no warning, no CHANGELOG note.
Related: OpenAPITools/openapi-generator#24095 (bug report) and #24607 (fix — pattern-matches the
AuthDatavariant at the call site to use the untyped API safely).Proposed fix
Scheme-typed accessors alongside (or instead of) the untyped one, e.g.:
so intent is explicit at the call site, matching 6.x's ergonomics.
Fallback
If a typed API isn't wanted, at minimum a doc comment on
from_headers(and a CHANGELOG entry) calling out the 6.x→7.x behaviour change would help — worthwhile on its own even alongside typed accessors.