Module auth 

Bearer-key authentication and per-request metering (Phase 2 design §4, §5).

This module is the only place a secret is ever visible: handlers receive a KeyId (and, since paid-path S2, the key’s KeyPlan) and nothing else, so a handler cannot leak a secret by accident and the metering layer has a stable identity to record without touching the credential.

Order of operations per request:

1. Read Authorization and require the exact form Bearer <key_id>:<secret>.
2. Verify against the runtime KeyStore in constant time. The store is read on every request, so issuance, rotation, and revocation take effect without a restart (see crate::keys).
3. On success, attach KeyId and KeyPlan to the request extensions.
4. Enforce the plan’s monthly query quota against the metering log (paid-path S3): a key at its limit is answered 429 and, like a 401, is not metered.
5. Run the inner service.
6. Measure the response body and append exactly one metering record.

A rejected request (step 1 or 2) is answered 401 and is not metered. See the deviation note in crate::metering.

Structs

AuthMetering

Everything the auth + metering layer needs, shared by reference.

KeyId

The authenticated key_id, attached to the request by [auth_and_meter].

KeyPlan

The authenticated key’s plan, attached beside KeyId by [auth_and_meter].

Constants

MAX_RESPONSE_BYTES

Largest response body the middleware will buffer in order to measure it.

Functions

metered

Wraps router so every route requires a bearer key and is metered.