Platform administration and site settings

Updated 22 October 2026 (Africa/Nairobi). Apply migration 017_platform_site.sql before deploying this increment to an existing database. Take a database backup first. Fresh installations apply it through the initialization runner. The dashboard's database identity owns these new tables; no tenant API, worker or agent role is granted access to OAuth credentials, contact messages or individual analytics state.

Platform Admin

Sign in with a platform super_admin identity and choose Platform Admin in the dashboard. This page lists registered accounts in pages of 50, seven-day signups, workspace/online-server counts, the latest 50 contact enquiries, recent aggregate visit statistics, sign-in provider configuration and the existing legal editor/request queue. Ordinary workspace owners do not receive platform administration access. Native API guards recheck the authenticated user's current platform role; pending MFA sessions cannot access the panel. Responses are private and non-cacheable.

Google and GitHub sign-in

Create the relevant OAuth web applications with the providers, then enter their client IDs and secrets in Platform Admin. Google uses https://ownserva.com/api/auth/callback/google; GitHub uses https://ownserva.com/api/auth/callback/github. These must match the provider's configured callbacks. Follow Google's web-server OAuth instructions and GitHub's OAuth application flow.

Saving requires the administrator's current password, an authenticated completed-MFA session where applicable, an exact same-origin POST and a committed per-account attempt limit. An administrator without a password must set one using the existing verified account flow first. Secrets are encrypted using ACCOUNT_ENCRYPTION_KEY, AES-256-GCM and provider-specific authenticated data; the panel returns only secret-presence flags. Blank secrets retain the existing value. Back up this key; losing it prevents decryption. Changing configuration is audited without including credentials.

Settings apply to new OAuth requests without a restart. A stored disabled provider overrides environment defaults. Existing sessions remain valid until revoked normally. Environment credentials remain a fallback when a provider has no database setting. Database outages do not reactivate a provider that an administrator disabled. Saving configuration is not an external credential-validation test: complete a real provider sign-in after configuring approved OAuth applications. New-account OAuth registration still requires the published legal package; explicit provider linking and MFA rules continue to apply. GitHub sign-in credentials do not authorize private repository deployments, which retain per-application scoped credentials.

Cookies and visits

The public banner offers equally styled Essential only and Accept optional analytics actions, an unchecked analytics choice and preference saving. Refusal is remembered; Cookie preferences in the footer reopens the controls. Preferences last up to 180 days. Global Privacy Control and Do Not Track disable optional analytics, including server-side handling.

First-party visit events are sent only after analytics consent on allowlisted public pages. No query strings, fragments, private account pages, request forms, IP addresses, user agents, referrers, account IDs or cross-site identifiers are stored in analytics tables. A separate HttpOnly visit cookie identifies an anonymous 30-minute session. Unique event IDs deduplicate repeated page submissions. New visits mean sessions, not unique people or all traffic; opted-out visitors and robots without analytics consent are not counted. Counts begin with this release, with no invented historical values.

The maintenance worker removes expired anonymous sessions and event deduplication IDs older than 24 hours through the existing cleanup function. Daily aggregate counts remain for operational reports. Dates use Africa/Nairobi. Withdrawing consent stops future events and clears the optional cookie; it does not alter prior aggregate totals. Request-volume limits bound analytics ingestion. The server's existing security/access logs remain separate from these analytics tables and need their own operating retention policy.

Contact and policy pages

Contact Us provides support/privacy addresses and a persisted enquiry form with origin checks, bounds, a honeypot and per-email/global rate limits. It returns a reference immediately. Messages appear in Platform Admin and can be marked new, in review or resolved. Status changes do not send email or imply the enquiry has been answered; use the support mailbox to reply. Configure SMTP separately for account verification and security proof delivery.

The old development/compliance warning is replaced by a concise policy-update notice. Draft service terms remain labelled and the publication/checkout/signup gates remain unchanged. This presentation change does not publish or approve unfinished policies. Complete operator-specific privacy, retention, transfers, tax and refund arrangements before public commercial onboarding.

Public discovery and documentation

Public pages have individual metadata, descriptions, canonical URLs, social cards, an Organization/WebSite description, a sitemap and robots instructions. Private account, setup and API routes are excluded from discovery. This improves technical search readiness without promising search rankings or indexing. Production documentation is served locally at /docs/<guide> with safe Markdown rendering and working local guide/download links; it does not require repository access.