auth/resolved_auth.ts

Gather the credential the auth middleware resolved for this request.

Reads the keys the session, bearer, and daemon-token middleware set and keeps only the one that belongs to the winning credential type — a daemon token overrides a session cookie sent alongside it without clearing that session's hash, so the hash is carried for a session credential alone.

An authenticated request's credential, account-grain — no actor.

token_hash is set for a session, api_token_id for an API token, and both are null for a daemon token. The twin of the Rust spine's ResolvedAuth, which carries the account row and token scope as well; here those stay on the Hono context.

Re-check that a resolved credential still authenticates: true when it does, false when it has been revoked, has expired, or its account is gone.

For a connection that outlives its request — a WebSocket, an SSE stream — and is authorized once, at open. Such a connection is closed on revocation by identity, but only once it is *registered*; between the credential read and the registration a revocation closes nothing. So the opener registers first (un-admitted — BackendWebsocketTransport.register_pending / SubscriberRegistry.subscribe_pending), then calls this, then admits. A revocation that committed before this read is seen by it; one whose close ran after the registration found the pending entry.

That needs each statement here to see everything committed before it started, so deps.db must be the pool-level Db (autocommit) or a READ COMMITTED transaction — never a REPEATABLE READ / SERIALIZABLE transaction opened before the registration, whose snapshot would predate it.

What is re-read, per credential — each through the same predicate the resolve path used, so the two cannot disagree about what "valid" means (the session and account legs call the middleware's own queries; the token leg shares its WHERE fragment):

• Session — the auth_session row still exists, is unexpired, and belongs to the resolved account.
• API token — the api_token row still exists, is unexpired, and belongs to the resolved account (by id; the raw token is not kept).
• Daemon token — nothing of its own. The token has no row, and no revocation event: rotation closes no connection, so there is no close an opening connection could have missed. Its keeper account is still re-read.
• Every credential — the account row still exists and is not soft-deleted.

It re-checks the credential, not what a revocation chose to close: a logout closes every connection of the account but deletes only its own session, so another session's connection opening concurrently passes this check and is refused only if that account-wide close found its pending registration — the same two outcomes an already-open connection has.

No side effects. Unlike the bearer middleware this never touches api_token.last_used_at / last_used_ip — re-checking a credential is not using it — and it writes nothing else.

A ResolvedAuth whose credential type lacks its own key (a session with no token_hash, a bearer with no api_token_id) is a shape the middleware never builds; it is answered false.

The twin of the Rust spine's revalidate_resolved_auth.