Skip to main content
Identity plugin · listing tai42/accounts-postgres

​
Install

​
Permissions

​
Provides

​
accounts-postgres

Identity — Postgres-backed accounts/identity provider — owns user accounts, password login, sessions, and invites.

​
login

Router — The public /api/login/* routes.

​
users

Router — The authed /api/auth/users* user-administration routes. Provides human logins on Postgres — an email and password, a session, and a role — and contributes the Studio’s Users screen. The account model itself stays central; see Accounts. This page wires the provider and its two routers.

​
accounts-postgres

The identity provider. Mount it with both routers and register it as an auth provider:
manifest.yml
Mounting the routes without registering the provider raises at boot, naming both settings — the two halves are never half-wired.

​
Connect the database

The provider carries no connection of its own. It binds to a named database through TAI_DB_BINDING_TAI42_ACCOUNTS_POSTGRES (default default) and uses that database’s connection, keeping its own tables inside it. A single-database deployment leaves the binding unset and configures TAI_DATABASE_DEFAULT_PG_*; give accounts its own database by binding it to another declared name and configuring that one:
The provider is on when its bound database is configured — a non-empty password — and cleanly off otherwise. Pool sizes and timeouts are tuned on the database itself (TAI_DATABASE_<NAME>_PG_*), not a variable of this package’s own. Sessions live in Postgres; login backoff and the bootstrap token live in Redis, which arrives from the access-control configuration.

​
Run the migrations

The plugin ships a migrations/ folder and declares it in its descriptor, so the shared runner discovers it as the tai42-accounts-postgres component and applies it alongside the core chain:
The provider asserts its chain at boot and never applies it for you: with the store configured but the chain pending, the process refuses to start, naming tai db migrate.

​
Tune sessions and login limits

​
login

The public /api/login/* routes. The first owner is created through POST /api/login/bootstrap, and the Studio’s login screen offers it while no user exists. The call is gated by a bootstrap token:
Set the token yourself, or leave it unset and let the server mint one at startup — it is generated once, stored in Redis, and logged by the process that wins the race, so read it from that process’s logs. The call creates the owner with the admin role and refuses with a conflict once any user exists. Passwords are at least ten characters.
TAI_ACCOUNTS_BOOTSTRAP_OPEN=true disables the token gate entirely. It exists for local development. Never set it on a reachable deployment.

​
users

The authed /api/auth/users* user-administration routes. There is no outbound email — creating a user returns a one-time invite link you deliver yourself. role names an existing access-control role template; an unknown name is rejected and no user is created. The response carries an invite token and a /login?invite=... path relative to your origin; the invitee sets a password through POST /api/login/invite/accept, which consumes the token and mints a session in one step. Re-issue an invite with POST /api/auth/users/{user_id}/invite — it refuses once that user has a password. The Studio’s Users screen drives the same routes, and the last enabled admin cannot be demoted, disabled, or deleted.

​
See also