Module auth 

Authentication wiring — RFC 2326 §14 (RTSP reuses HTTP auth).

RTSP shares HTTP’s Basic and Digest schemes verbatim (RFC 2326 §16); see docs/auth.md. The Credentials model and the challenge-parsing/response-computation logic now live in the shared broadcast_auth crate — re-exported here so rtsp-runtime callers keep using rtsp_runtime::Credentials/Authenticator unchanged. This crate contributes only the one RTSP-specific rule: the uri used in the digest computation is the RTSP request URI (e.g. rtsp://host/stream), not an HTTP URL (RFC 2326 §14) — client::ClientSession passes it through as-is.

Sharing this logic with HTTP clients (rather than re-implementing it per client) is the point: broadcast-auth also backs multimux’s HTTP input adapters (TS-over-HTTP, HLS-pull) and adds Bearer (RFC 6750), which this crate did not previously support.

Structs

Authenticator

Negotiates a challenge once, then answers every subsequent request in the session (RFC 7235 WWW-Authenticate/Authorization; RFC 2326 §14 for RTSP; RFC 6750 for Bearer).

RequestContext

The request fields the Digest response hash covers (RFC 7616 §3.4.1 / RFC 2326 §14): the method, the request URI, and — for qop=auth-int — the body. Also carries the request’s headers and transport peer address, so a server-side crate::Verifier scheme can see beyond the Authorization header — e.g. a reverse-proxy forwarded-auth scheme reading X-Forwarded-User/X-Forwarded-For (issue #663 extensibility wave part 1). Client-side use (crate::respond/crate::Authenticator) needs neither field; Self::new defaults both to empty/None.

Enums

Credentials

Credentials for one of the supported auth schemes.