ekklesiaandClaude Opus 5.5
a4966dd0dd
CI / verify (pull_request) Successful in 50s
CI / infrastructure-smoke (pull_request) Successful in 21s
CI / migration-smoke (pull_request) Failing after 25s
CI / image-build (pull_request) Successful in 18s
CI / deploy-smoke (same-origin) (pull_request) Successful in 49s
CI / deploy-smoke (split) (pull_request) Successful in 1m17s
An installation can now serve the Dashboard and the API on sibling hostnames (dash./api.) beside the default same-origin topology, from one image and with configuration alone. - The Dashboard learns its API origin at run time: the built page carries one empty <meta name="ekklesia-api-origin">, which the API fills with its identity base URL's origin at startup, before computing the page's ETag. The shell accepts only a canonical http(s) origin and otherwise fails closed without making a request. The build-time EKKLESIA_API_BASE_URL is gone from the bundle; the development server injects the same element. - The display host stays on the API's origin, so its device cookies, requests, and offline cache are unchanged. - The API trusts its own origin (trusted origins plus the identity base URL), as Better Auth already does, so the display page's mutations pass the origin check without operators listing it. - Doctor validates EKKLESIA_DASHBOARD_ORIGIN exactly as the API's startup does (it previously skipped it), reports the topology without printing hostnames, and warns when split hostnames are not siblings. - The module UI contract states the CORS header limit (safelisted headers plus Content-Type, safelisted response headers only). - Reference deployment: Caddyfile.split.example (Dashboard hostname serves / and its script; API hostname serves /api/*, /display/*, and the display script; each refuses the other's paths) and EKKLESIA_DASHBOARD_HOSTNAME in the proxy overlay and env examples. - The deploy smoke test runs either topology (CI runs both). The split run installs the module template as a test-only module, checks per-hostname routing and exact CORS, then drives a digest-pinned headless Chromium over the DevTools protocol, with no added dependency: sign-in on the Dashboard hostname, the session cookie host-only on the API hostname, the module UI imported cross-origin and its credentialed request succeeding, the display and its service worker on the API hostname, and sign-out. ADR 0045 is marked Accepted. Co-Authored-By: Claude Opus 5.5 <[email protected]>
24 lines
1.3 KiB
HTML
24 lines
1.3 KiB
HTML
<!doctype html>
|
|
<html lang="en" style="min-width: 0; scrollbar-gutter: stable">
|
|
<head>
|
|
<meta charset="utf-8" />
|
|
<meta content="width=device-width, initial-scale=1" name="viewport" />
|
|
<!-- The API's origin (ADR 0045). The API serving this page fills it in at startup; empty means
|
|
this page's own origin, the same-origin topology. Never an inline script, so a strict
|
|
script-src needs no exception for it. -->
|
|
<meta content="" name="ekklesia-api-origin" />
|
|
<title>Ekklesia</title>
|
|
</head>
|
|
<body style="margin: 0; min-width: 0">
|
|
<!-- The shell's root. A module UI never receives this element: it is given a container the
|
|
shell creates inside its own layout. -->
|
|
<div id="ekklesia-host"></div>
|
|
<!-- A real module script, from the same origin, with no inline script anywhere on the page:
|
|
a deployment can therefore apply a strict script-src without exceptions, and the runtime
|
|
`import()` of a published module artifact stays same-origin under it. The path is absolute
|
|
and fixed, exactly like the display host's, so it names one host-owned route rather than a
|
|
file relative to whatever URL served the page. -->
|
|
<script src="/assets/ekklesia-dashboard/app.js" type="module"></script>
|
|
</body>
|
|
</html>
|