Struct AuthManager 

pub struct AuthManager { /* private fields */ }

Selects exactly one active auth strategy per deployment, chosen via the auth_method config value (REQ-1.2.3) — there is no runtime engine for resolving multiple simultaneously-required schemes.

Implementations

impl AuthManager

pub fn new(auth_method: AuthMethod) -> Self

pub async fn login(&mut self, config: &AuthConfig) -> Result<Credentials>

pub fn set_credentials(&mut self, credentials: Credentials)

Seeds in-memory credentials directly, bypassing OS-keychain/file storage entirely — for tests (which must never touch the real OS keychain as a side effect of running) and for callers that already hold validated credentials from elsewhere.

pub async fn credentials(&mut self) -> Result<Credentials>

pub async fn apply_auth_headers( &mut self, headers: HashMap<String, String>, method: &str, url: &str, transport: Transport, request_override: Option<&RequestCredentials>, ) -> Result<HashMap<String, String>>

Decorates outgoing request headers with credentials for transport: on Transport::Http, request_override (extracted per-request from the caller’s own headers — see http::auth_extractor) is the only source ever consulted, since HTTP deployments must never leak the operator’s local config/keychain secrets to a caller who didn’t supply their own; a missing override is a hard error, not a fallback. On Transport::Stdio, request_override is ignored and behavior is unchanged from before HTTP-transport support existed: self.credentials() (config cascade + keychain).

API-key placement (header vs. query, and the header/param name) defaults to an X-Api-Key header here; a scheme declaring a different location is one of Story R6’s api-client responsibilities to refine, not this manager’s — request_override’s request_header_name/request_header_value pair is the one exception, since the HTTP path already knows the scheme’s declared header name (RsAuthSchemeView::header_name) at generation time.