Accounts, keys and permissions

All three services of Live Caption Pro authenticate, and this cannot be turned off. Users, passwords and API keys live in one place: the account service (accountserver). Installation is on the Installation page; this guide is about everyday use.

Terms

The account service and its database

Users, keys and permissions live in a PostgreSQL database; the local database is run in the machine's Docker by the repository's AccountServer\managed-postgres.cmd launcher. Several instances of the account service may run on the same database – on one machine or on several: they see the same users and keys, and a web sign-in obtained on one is valid on the other.

The services, however, know a single address: the one in the LCP_ACCOUNT_URL environment variable (set by the AccountServer\setup-account-peers.ps1 script), and it is mandatory: without it the services do not start. A second instance is therefore a standby today – if the first one fails, it can be taken into use by changing the address. Every half minute the services download the permission snapshot (a copy of the users, keys and rights) from the account service and decide locally. Sign-in, however, is forwarded to it, because the snapshot carries no password hash. The price: while the account service (or its database) is down there is no new sign-in, but sessions already signed in keep living.

Backing up the database is manual: AccountServer\managed-postgres.ps1 -Backup, restoring it -Restore <file>. The backup contains password hashes, so treat it as confidential; the web sign-in keys are deliberately left out of it, so after a restore everyone has to sign in again.

The first login

The first start – on an empty database brought up beforehand by managed-postgres.cmd – creates an entry named admin and prints its random password once, in its own window – never to the log. That is why the first start happens in the service's visible window (start-accountserver.cmd); maintenance mode does not create an initial admin. With it you sign in to the web admin at http://127.0.0.1:8101/admin, where the page immediately asks for a new password. Afterwards users and keys come from the Users and Keys pages, or from maintenance mode – a command-line operation that runs instead of serving (-UserAdd, -KeyAdd).

Roles

The scope cannot be omitted: a role applies to one service or to all. From maintenance mode:

.\start-accountserver.ps1 -RoleGrant kati -Role Operator -Scope voiceserver

API keys

The shape of a key:

lcp_<azonosító>_<titok>

• The identifier (azonosító) is public; the secret (titok) is never stored, only its hash (SHA-256). The full key is shown once, at creation.
• The default expiry is 365 days. Rotation creates a new key and gives the old one a grace period (7 days by default); during the overlap both work.
• Revocation is immediate, without a grace period.
• A key never grants more than its owner has.

A key is created on the web Keys page or in maintenance mode:

.\start-accountserver.ps1 -KeyAdd kati -KeyName "a laptopom"

The caption program receives it on the Servers tab and stores it encrypted, bound to the user account – it cannot be carried to another machine. The command-line scripts get their own key from generate-api-key.cmd. Access for another machine or user – an account, the AppUser role and all three keys – is issued in one step by generate-user-key.cmd, which prints the secrets to the console and, on request, to a file.

Lost password

The way out is maintenance mode on the account service's machine – it works even when the service is not running (the database, however, must be running):

.\start-accountserver.ps1 -UserPassword admin

There is deliberately no command-line password: it comes from standard input in a single line, or the program draws one and prints it once. Setting a password invalidates every open browser session.

Audit log

Who did what, when, and what came of it: deliberate operations are kept for 400 days, and the Audit log page shows them with filters. A rejected attempt is a row too. No secret ever gets into them. Everyone's rows need the audit.read.all right, your own need audit.read.own.

Usage metering

How much work we did, for whom, and with what weight: the rows are on the Usage page, the multipliers are set on the Pricing page. There is deliberately no price and no currency – only measurement and a per-model weight.

The spoken text, the caption and the translation result never get into the metering. The multiplier is fixed at the time of use and frozen into the row: a later price change does not rewrite the past. Raw rows are kept for 62 days, the daily totals permanently.

If you get stuck: Troubleshooting, or the Contact page.