Trait AuthProvider

Source

pub trait AuthProvider: Send + Sync {
    // Required method
    fn auth_header(&self) -> Option<(&str, &str)>;
}

Expand description

Injects per-request authentication credentials.

Separate from transport configuration (TransportConfig) so any credential scheme can be paired with any transport.

Implement this trait when you need a custom Authorization header or other per-request credential scheme. For custom TLS/trust-root logic implement TransportConfig instead. NoneAuth, BearerAuth, and BasicAuth cover the common cases.

Implementations must not log the return value of auth_header; it contains credentials.

Maintainer note (bd:JMAP-6lsm.19): if you add a new method to this trait, update BOTH manual blanket impls — Box<dyn AuthProvider> and Arc<dyn AuthProvider> — at the bottom of this file. The crate supports both Box and Arc trait-object call shapes (e.g. for sharing one credential source across multiple JmapClients), and a missing blanket method silently breaks one of those shapes without breaking the other.

Required Methods§

Source

fn auth_header(&self) -> Option<(&str, &str)>

Return an optional (header-name, header-value) pair to attach to every request.

Returns None when no Authorization header is required.

Both strings borrow from self and must live at least as long as the &self borrow. Implementations that pre-compute the values at construction time can return &self.field directly, avoiding any per-request allocation.

§Implementation contract

The returned strings must be valid HTTP field values (RFC 9110 §5):

Header name: lowercase ASCII token characters only (no spaces, no control characters); e.g. "authorization".
Header value: visible ASCII characters (0x21–0x7E) and horizontal tab (0x09) only; no other control characters.

Implementations that violate this contract will cause ClientError::InvalidArgument in connect_ws (ws/mod.rs), which parses the value into a typed http::HeaderValue. On HTTP code paths reqwest returns the error from .send() as a builder error rather than an InvalidArgument — the error type differs between the two paths. Test all custom AuthProvider implementations against both HTTP and WebSocket call paths.