Serving sign-in from the fleet

Serving sign-in from the fleet

A hosted project's accounts live in the database itself, in its auth schema (users, identities, sessions, refresh tokens, multi-factor factors), and migrate restores that schema with everything else. What answered /auth/v1 was the provider's server, Supabase Auth (GoTrue), which is open source, so the fleet runs the same server over the same tables:

stado database auth place <name> --port <port> --ready-within <seconds>

places it beside a fleet database as the unit <name>-auth, on the host the database runs on or over the host channel from any machine of the fleet. A password, an OAuth link or a refresh token the provider issued keeps working, because the server reads the rows it wrote there.

• The server is the release stado-rs/data/declarations/supabase-auth.json pins, installed under ~/.local/share/stado-supabase-auth/<version>. Its publisher puts no checksum list beside its archives, so the declaration pins each platform's sha256 as GitHub's release record states it, and an archive with any other digest is refused before it is unpacked. It listens on --port of every IPv4 interface, as the database and PostgREST do, so the gateway reaches it on the loopback and a host whose network moves keeps answering. A new placement refuses a port a server of a database on the host declares (this database's own REST API included) or another program listens on, as rest place does, with the same sentences naming the sign-in server.
• The role supabase_auth_admin is made (or given a new password) and owns the auth schema and everything in it, as on the provider, with its search path set to auth as the vendor sets it; the server migrates the schema to its release when it starts, and its migrator makes its own bookkeeping table in that search path.
• The settings are the project's own, read from the management API (GET /v1/projects/{ref}/config/auth): site URL, allowed redirects, every provider with its client id and secret, mail, token lifetime. The project is the one the item names, else the one <name>-database-previous (kept by migrate) names, else --from-project <ref>. When the project is gone they are given with --settings-file <file>, the same object, naming at least site_url. Such a file names no secret: each --secret-setting KEY=ROLE#FIELD reads field FIELD of the owner-vault item playing role ROLE and writes it as setting KEY (smtp_pass=resend-api#value, external_google_secret=oko-google-oauth#client_secret); it is read on the vault owner before the settings travel to the database's host. A key the management API names differently from the server (refresh_token_rotation_enabled) is written under the server's name. Everything is written with the placement's own database address, port and signing secret into ~/.stado/databases/<name>/auth.env, readable by its owner only.
• The mail templates (mailer_templates_<kind>_content, the bodies the provider sends sign-in mail with) are files the server reads only from a URL. They are written to ~/.stado/databases/<name>/mail-templates/<kind>.html and the server is told to read them from the database's gateway (next section), so the gateway is placed first; settings carrying templates with no gateway are refused naming the kinds.
• The address clients reach is <url>/auth/v1 when the item records the gateway's public url, else auth_url: the server builds its mail links on it, and every provider the settings enable without naming its callback (external_<provider>_redirect_uri) is given <that address>/callback, which the provider's OAuth client must list. The report names each callback under provider_callbacks.
• The tokens it issues are signed with the item's jwt_secret, the one rest place gave PostgREST, so a signed-in user's token opens the REST API under the row policies the data was written with; place the API first.
• The item gains auth_url, auth_port, auth_version and auth_settings_from.

The server migrates before it listens, so after the unit starts /health is asked once a second until it answers or --ready-within seconds pass; Stado assumes neither that time nor the port. A placement already made is reported reused; --reconfigure reads the project's settings again, writes them and restarts the unit. A gateway in front of the database is written again so /auth/v1 reaches the server (gateway_routes_auth).

stado database auth retire <name> stops and forgets <name>-auth and takes its fields off the item; the auth schema and its accounts stay, since they are the database's data, and a gateway stops routing /auth/v1. destroy retires the gateway, sign-in, then the REST API, then the database. Every refusal is listed under Every database command.