Portal & console

Two ways to run a SuperDRM tenant: the portal, self-service for companies on the hosted service (and optional on an on-prem install), and the operator console, for the people who run an install.

#The portal — superdrm.com/portal

A company signs up, verifies its email, proves domain ownership, and runs DRM on a metered plan. A company account is a tenant plus its members; everything downstream (keys, licences, metering, attestation) is per tenant.

#Lifecycle

1. Sign up — company name, email and password. The tenant is created immediately on the developer plan in pending status with its API key and token secret (shown once), but the licence endpoints refuse until the email is verified.
2. Verify email — the link in the mail activates the tenant and signs you in.
3. Verify a domain — the portal issues a TXT record (_superdrm.<domain>); a DNS-over-HTTPS check flips it to verified. A verified domain is required for any paid plan.
4. Operate — API keys, usage (a meter bar, 14-day bars, live events), domains, team invites (owner / admin / member), plan changes, session management and the account switcher — all in the portal.

#Signing in

Email and password, or Sign in with sup. Passwords are stored with scrypt; sessions are 30-day secure HTTP-only cookies, hashed server-side; a password reset revokes every other session; sign-in, sign-up and reset are rate-limited per address. Email tokens are single-use, hashed at rest and burn on first use. The account switcher lists every tenant your sup identity can reach; Add account signs into another one without signing out.

#Metering and plans

The meter is the licence table: one event per licence grant, rolled up daily. Plans define included_licences and included_keys per month:

• a plan with overage pricing keeps granting past the include; overage is billed per 1,000;
• a plan without overage returns a clean 429 quota_exceeded naming the plan and the limit. Key creation has the same gate.

Quota state is visible on the Overview (meter bar and a blocked banner) and costs one cached query per tenant per minute on the licence path.

#Portal API

Everything the portal does is plain JSON under /v1/portal/* (session cookie sdsess; all writes need the X-SuperDRM-Portal: 1 header). superdrm.com proxies /v1/portal to the API same-origin so cookies stay first-party; the raw API host serves it too.

#Master admin — superdrm.com/admin

Sign in with a user flagged is_master. Accounts table (plan, status, suspend/activate, manual email verification for support), users, cross-tenant usage, audit trail. Grant or revoke the flag with the operator token — POST /v1/admin/users/<email>/master {"on": true} — so the first master is bootstrapped by the operator, and losing the portal never locks you out (the operator-token API is independent). Suspension is immediate: the licence path re-reads tenant status per request.

#The operator console

apps/console is the operator's view of an install: a server-rendered application that shows everything the CLI does, with tables and charts.

#Running it

cd apps/console
cp .env.example .env.local     # SUPERDRM_API_URL, SUPERDRM_ADMIN_TOKEN
npm install && npm run build && PORT=8771 npm start

Or as the console service under Compose / Helm, or the ops/superdrm-console.service user unit.

#Access

The console has no login of its own. The operator token stays server-side, but anyone who can reach port 8771 can operate every tenant. Expose it only behind your own gateway (email + passkey, SSO) and never as a bare public route. The console mints one read-only API key per tenant per process start (named console (read)) to read tenant-scoped data; those keys are harmless and visible in each tenant's API keys tab.

#The live console

apps/live relays the api's server-sent event stream and draws the whole install as a node canvas: every licence, key and admin action as it happens, plus an EME demo player. It shares the docs password on an install.

#Email

The portal sends verification, reset and invitation mail through any STARTTLS relay configured in mail.json (host, port, user, pass, from), read per send with no restart. Without it the mailer logs the link instead, and SUPERDRM_MAIL_FALLBACK_LINKS=1 (tests and development only) also returns it in API responses.

Updated September 2026