fix(ui): package the OIDC silent-callback page so it actually works

[thjaeckle]

Problem

ui/silent-callback.html has never worked in any environment. It was added by c2eda4f "support silent token refresh" alongside the OIDC wiring in authorization.ts, but the packaging half was never done — and the page carried two further defects that only a real browser would surface.

1. It never reaches the image. ui/Dockerfile copies only ./index.html and ./dist; the page sits at ui/ root, so it is copied by neither. Confirmed inside a running eclipse/ditto-ui container rather than inferred: the web root holds index.html, 50x.html and dist/{main.css,main.js}, and a filesystem-wide search for *callback* returns nothing.

2. build.mjs could not have supplied it either. It has a single entry point (main.ts), and its .html loader is text — which inlines HTML imported from TypeScript as a string rather than emitting standalone HTML files. Nothing imports the page, so COPY ./dist had nothing to pick up.

3. The page could not run even if served. It did:

import('oidc-client-ts').then(({ UserManager }) => {
    const userManager = new UserManager();

'oidc-client-ts' is a bare ESM specifier — unresolvable without an import map, and the page has none. And new UserManager() with no argument throws: UserManagerSettingsStore dereferences args.redirect_uri before any defaulting.

Why it went unnoticed. The only reference to the page anywhere is the environmentTemplates.json default, http://localhost:8000/silent-callback.html — the esbuild dev server, whose servedir: '.' made the file reachable during local development and masked all three problems. Beyond that, UserManager.signinSilent() returns from its refresh-token branch whenever user?.refresh_token is set:

if (user?.refresh_token) {
  return await this._useRefreshToken({ ... });
}

so any client requesting offline_access never loads this page at all.

Fix

• ui/silent-callback.ts (new) — the script becomes a real entry point, so esbuild resolves and bundles oidc-client-ts instead of leaving a bare specifier.
• ui/build.mjs — entryPoints: ['main.ts', 'silent-callback.ts'].
• ui/silent-callback.html — loads ./dist/silent-callback.js, mirroring how index.html loads ./dist/main.js.
• ui/Dockerfile — COPY ./silent-callback.html .

The placeholder settings in silent-callback.ts are deliberate and commented: signinSilentCallback() delegates to IFrameNavigator.callback(), which reads nothing from the settings but the optional iframeNotifyParentOrigin (defaulting to the page's own origin). authority and client_id are required by UserManagerSettings but never touched on this path — and passing an object at all is what avoids the constructor throw.

Also included: ui/.dockerignore

With no .dockerignore, the whole ui/ tree went to the daemon as build context — node_modules included — so a three-COPY build took minutes. An allowlist was chosen over a denylist so that adding a COPY without extending the list fails the build rather than silently depending on whatever is lying around in the working tree.

Build time drops from minutes to ~10s, and the image contains a byte-for-byte identical set of files.

Verification

• npm run build (tsc -noEmit && node build.mjs) passes, emitting dist/silent-callback.js (65 kB).
• The bundle carries the real contract — the "oidc-client" message source, postMessage and keepOpen are all present — with 0 dynamic imports and 0 unresolved bare specifiers.
• Building ui/Dockerfile and serving the image:

Path	Status	Content-Type	Bytes
/silent-callback.html	200	text/html	172
/dist/silent-callback.js	200	application/javascript	65705
/index.html	200	text/html	7401
/dist/main.js	200	application/javascript	945817

• Image contents identical before and after adding .dockerignore: 50x.html, index.html, silent-callback.html, dist/{main.css, main.css.map, main.js, main.js.map, silent-callback.js} at the same sizes.

Not verified

The renewal round trip itself needs a browser session with an IdP that issues no refresh token, waiting for an access token to approach expiry — I could not exercise that. What is verified is that the page and its bundle are served correctly and that the bundled code contains the message contract AbstractChildWindow validates.