Providers create the credential the mesh minted, sealing nothing (ADR 0053)

redis, postgres and minio adapters drop generatePassword + the returned credential:
each creates the resource under the login the mesh derived (`as`) with the password
the mesh minted (`p.password`). minio's client gains a secret-key argument so it sets
the mesh's secret rather than generating one. umami (analytics) is re-pointed at the
new contract too; its siteId return is a data-provision concern ADR 0053 scopes out.

Proven: mesh-lab provider-uses-mesh-credential green — redis creates the consumer's
login with the mesh's password, the consumer authenticates (PONG), no seal key set.

Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
This commit is contained in:
2026-09-05 00:27:37 +02:00
parent 550393b847
commit 3b03fcd8f7
5 changed files with 107 additions and 139 deletions
+23 -19
View File
@@ -1,35 +1,39 @@
// umami's provisioner — the adapter that makes umami a provider of the mesh `analytics` interface.
// The watching, sealing and grant-file handling are the sdk harness's; this writes only the
// per-service half: how umami creates and removes a tracked site (novox/hq ADR 0044/0045).
// The reconcile loop and the contributions file are the sdk harness's; this writes only the
// per-service half: how umami creates and removes a tracked site (novox/hq ADR 0044/0045/0053).
//
// The `analytics` interface: a consumer contributes `{ domain }` (the site it wants tracked) and
// receives `{ siteId, snippet, dashboard }`. umami adapts its own API to that contract, so a
// consumer depends on `analytics`, not on umami.
// receives `{ siteId, snippet, dashboard }`.
//
// **A note on scope (ADR 0053).** ADR 0053 corrects *credential* provisions: the mesh mints a secret
// and the provider creates a login with it. Analytics is not that shape — it mints no secret the
// consumer authenticates with; what the consumer needs back is data umami *generates* (the siteId).
// The credential-provisioner contract returns nothing, so the siteId does not travel back to the
// consumer here. That return path — for a provider that generates data rather than being handed a
// secret — is a separate concern and is not solved by this decision. umami still reconciles its
// sites off the mesh's contributions (it keys on the login the mesh derived), which is what this
// keeps working.
import { runProvisioner, type Grant, type Credential } from "@novox/mesh-sdk/provisioner";
import { runProvisioner, type Provision } from "@novox/mesh-sdk/provisioner";
import { UmamiClient } from "../client.js";
const umami = UmamiClient.fromEnv();
runProvisioner("analytics", {
async create(grant: Grant): Promise<Credential> {
const domain = grant.values.domain ?? grant.consumer;
const name = grant.values.name ?? domain;
async create(p: Provision): Promise<void> {
const domain = String(p.values.domain ?? p.as);
const name = String(p.values.name ?? domain);
const token = await umami.getToken();
const site = (await umami.findWebsite(token, domain)) ?? (await umami.createWebsite(token, domain, name));
return {
fields: {
siteId: site.id,
snippet: umami.snippet(site.id),
dashboard: umami.dashboard(site.id),
},
};
// Idempotent: only create the site if it is not already there.
if (!(await umami.findWebsite(token, domain))) {
await umami.createWebsite(token, domain, name);
}
},
async remove(grant: Grant): Promise<void> {
const domain = grant.values.domain ?? grant.consumer;
async remove(p: { as: string }): Promise<void> {
const token = await umami.getToken();
const site = await umami.findWebsite(token, domain);
// Keyed on the mesh-derived login, the one identity the harness carries into removal.
const site = await umami.findWebsite(token, p.as);
if (site) await umami.deleteWebsite(token, site.id);
},
});