jcoffey-dev
501ac6550c
Contract C-4's singleton, which the INBUXA_ADMIN_URL, INBUXA_WEBMAIL_URL and INBUXA_WEBMAIL_CLIENT_SECRET environment variables have stood in for. It records the console's address, the webmail's and its client secret, and further allowed origins. Setting it registers the front ends' OAuth clients at once (C-6) and reloads the HTTP settings here and on every node, which puts the origins on the cross-origin allowlist (C-14): a front end on another machine can be added without touching the server's environment or restarting it. The installer's `inbuxa join` does exactly that. - A fork JMAP object like the other inbuxa: singletons, kept in the fork's subspace under Fe (open question 1, settled): upstream's generated schema is untouched. - webmailClientSecret is write-only, at least 32 characters, and stored only as its Argon2 hash; webmailClientSecretSet says whether one is. - /get needs sysHttpGet, /set sysHttpUpdate and sysOAuthClientUpdate; neither exists inside a tenant. Every change is audited. - The environment variables keep working beside it, both are honored, and where both give the webmail a secret the environment's wins, so setting one is refused while INBUXA_WEBMAIL_CLIENT_SECRET is set. /get shows what the environment says, so a refusal can be explained. Tests: system::front_ends::front_ends_tests (refusals, the clients and their redirect URIs, the secret proved by exchanging Ann's code as the webmail with a wrong and the right secret, the preflight answered for the console, the webmail and an extra origin and not for anyone else, clearing, the audit log); unit tests for the store, the URL checks and merging both sources. jmap_tests, branding, sharing_policy, audit_log, settings_reload, reload and system_tests pass (RocksDB). The installer's join e2e case passes against a build of this branch.