Skip to main content

Module operator

Module operator 

Source
Expand description

Signing in as the operator, over atproto OAuth, to reach this server’s operator controls.

One deployment has one operator, and this server was told which DID that is: --operator, held as didbot_pds::OperatorRelation’s operator_did and documented there as configuration. So authenticating an operator is establishing that whoever is asking controls that one DID, and the comparison at the end is a string equality against a value already in this process.

§Nothing is granted, and nothing is kept

The scope requested is atproto and nothing else: no repository access, no write, nothing this server could use even if it wanted to. It is an identity sign-in, and the only thing taken from it is the sub the operator’s own authorization server put in the token response. The OAuth session is dropped the moment the callback has read that — see OperatorAuth::finish — so no credential belonging to the operator is ever stored here. That is what keeps plan/handshake.md’s rule intact: a server reads who operates it out of configuration and a record in the operator’s own repository, and is never handed a secret to check.

What this server does issue is its own session, which says only “the browser holding this proved control of the operator DID at some point in the last OperatorAuth::session_ttl”. It is minted here, it never leaves this process, and it is not a credential any other party accepts.

§bot.did.operator is a different question

The operator poll reads a bot.did.operator record out of the operator’s repository to decide whether this server is claimed — the operator’s vouch for the server, fetched over the network. Sign-in does not consult it. Putting a remote fetch in front of a button press would make the operator’s controls unreachable exactly when their own server is unreachable, and an operator has business here — reading the onboarding surface, throwing the stop — before any claim has landed.

Structs§

OperatorAuth
The operator sign-in for one deployment.
Resolver 🔒
The identity resolution behind OperatorAuth.
Session 🔒
A browser that proved control of the operator DID.
SignedIn
What a completed sign-in hands the browser.

Enums§

SignInError
Every way signing in can fail before a session exists.

Constants§

CALLBACK_PATH
The path the operator’s authorization server redirects back to.
CLIENT_METADATA_PATH
The path this server publishes its client metadata document at. This URL is the client_id: an atproto client is identified by a document its authorization server can fetch.
DEFAULT_SESSION_TTL
How long a signed-in browser stays signed in, absent --operator-session-ttl or an [operator] section.
MAX_PENDING 🔒
How many sign-ins may be in flight at once.
PENDING_TTL 🔒
How long a started sign-in has to come back before its pending state is dropped. Generous enough for a consent screen and a password manager, short enough that an abandoned one does not linger.
SIGN_IN_SCOPE 🔒
The one scope this server ever asks an operator’s server for.

Functions§

is_loopback_redirect 🔒
Whether redirect names a loopback address on the machine running the command — the only place this server will hand a session it just minted.
random_token 🔒
256 bits from the OS, hex-encoded. Not a password and never stored anywhere but this process’s memory, so there is nothing to hash.