Where the front ends are, set over JMAP: inbuxa:FrontEnds #195

Merged

jcoffey-dev merged 1 commits from feat/front-ends into main

2026-10-12 13:23:01 +00:00

jcoffey-dev commented

2026-10-12 06:21:22 +00:00

Owner

Contract C-4's singleton, which the INBUXA_ADMIN_URL, INBUXA_WEBMAIL_URL and INBUXA_WEBMAIL_CLIENT_SECRET environment variables have stood in for.

What it does

inbuxa:FrontEnds/get and /set record the console's address, the webmail's address and its client secret, and any further allowed origins.
A set registers the OAuth clients immediately (C-6). It also reloads the HTTP settings here and on every node, which puts the new origins on the CORS allowlist (C-14).
So a front end on another machine can be added without touching the server's environment or restarting it. That's what the installer's inbuxa join uses (installer PR to follow).

Design

It's a fork JMAP object like the other inbuxa: singletons, stored in the fork subspace under Fe (checked unused). Upstream's generated schema is untouched, which settles the contract's open question 1.
webmailClientSecret is write-only, at least 32 characters, and stored only as its Argon2 hash. webmailClientSecretSet says whether one is set.
/get needs sysHttpGet. /set needs sysHttpUpdate plus sysOAuthClientUpdate. Neither exists inside a tenant. Changes are audited, and it's in the privacy catalog.
The environment variables keep working, and both sources are honored.
- If both give the webmail a secret, the environment's wins. So setting one is refused while INBUXA_WEBMAIL_CLIENT_SECRET is set; otherwise every restart would flip it back.
- /get shows what the environment says, so a refusal can be explained.
Not yet: C-1 discovery and C-18's admin lane don't read it, and the console needs a page for it (an admin PR).

Tests

system::front_ends::front_ends_tests:
- the refusals;
- both clients and their redirect URIs;
- the secret, proved by exchanging Ann's code as the webmail: a wrong secret gets invalid_client, the right one gets a token;
- the preflight answered for the console, the webmail and an extra origin, and for nothing else;
- clearing, and the audit log.
Unit tests for the store, the URL checks, and merging the two sources.
Pass (RocksDB): jmap_tests, branding_tests, sharing_policy_tests, audit_log_tests, settings_reload_tests, reload_tests, system_tests.
- system_tests failed once while the machine was loaded (a delivery test's Email/import unwrap), then passed on re-run, and passes on main the same way.
- scim_oidc_tests can't reach its OIDC container from the network namespace used here, which is an environment limit, not this change.
cargo build -p inbuxa --locked, the no-run build of every workspace test, and all fork checks pass.
The installer's new join VM case (24 checks, ending with a person signing in to the joined webmail) passes against a Debian 13 build of this branch.

Docs: contract C-4, C-6, C-14 and open question 1 updated. Divergence log V50 added (drafts).

Contract C-4's singleton, which the `INBUXA_ADMIN_URL`, `INBUXA_WEBMAIL_URL` and `INBUXA_WEBMAIL_CLIENT_SECRET` environment variables have stood in for. **What it does** - `inbuxa:FrontEnds/get` and `/set` record the console's address, the webmail's address and its client secret, and any further allowed origins. - A set registers the OAuth clients immediately (C-6). It also reloads the HTTP settings here and on every node, which puts the new origins on the CORS allowlist (C-14). - So a front end on another machine can be added without touching the server's environment or restarting it. That's what the installer's `inbuxa join` uses (installer PR to follow). **Design** - It's a fork JMAP object like the other `inbuxa:` singletons, stored in the fork subspace under `Fe` (checked unused). Upstream's generated schema is untouched, which settles the contract's open question 1. - `webmailClientSecret` is write-only, at least 32 characters, and stored only as its Argon2 hash. `webmailClientSecretSet` says whether one is set. - `/get` needs `sysHttpGet`. `/set` needs `sysHttpUpdate` plus `sysOAuthClientUpdate`. Neither exists inside a tenant. Changes are audited, and it's in the privacy catalog. - The environment variables keep working, and both sources are honored. - If both give the webmail a secret, the environment's wins. So setting one is refused while `INBUXA_WEBMAIL_CLIENT_SECRET` is set; otherwise every restart would flip it back. - `/get` shows what the environment says, so a refusal can be explained. - Not yet: C-1 discovery and C-18's admin lane don't read it, and the console needs a page for it (an admin PR). **Tests** - `system::front_ends::front_ends_tests`: - the refusals; - both clients and their redirect URIs; - the secret, proved by exchanging Ann's code as the webmail: a wrong secret gets `invalid_client`, the right one gets a token; - the preflight answered for the console, the webmail and an extra origin, and for nothing else; - clearing, and the audit log. - Unit tests for the store, the URL checks, and merging the two sources. - Pass (RocksDB): jmap_tests, branding_tests, sharing_policy_tests, audit_log_tests, settings_reload_tests, reload_tests, system_tests. - system_tests failed once while the machine was loaded (a delivery test's `Email/import` unwrap), then passed on re-run, and passes on main the same way. - scim_oidc_tests can't reach its OIDC container from the network namespace used here, which is an environment limit, not this change. - `cargo build -p inbuxa --locked`, the no-run build of every workspace test, and all fork checks pass. - The installer's new `join` VM case (24 checks, ending with a person signing in to the joined webmail) passes against a Debian 13 build of this branch. Docs: contract C-4, C-6, C-14 and open question 1 updated. Divergence log V50 added (drafts).

jcoffey-dev added 1 commit 2026-10-12 06:21:22 +00:00

Where the front ends are, set over JMAP: inbuxa:FrontEnds

ci / fork-checks (pull_request) Skipped

Details

ci / build (pull_request) Skipped

Details

github/ci (branch) GitHub Actions

Details

ci / github (pull_request) Successful in 7m6s

Details

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.

jcoffey-dev merged commit 9ce602cfe9 into main

2026-10-12 13:23:01 +00:00

jcoffey-dev deleted branch feat/front-ends

2026-10-12 13:23:01 +00:00

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: inbuxa/inbuxa-server#195