Peering admin panel: warn when a receivers list is group-only and no IdP admin client is configured #129
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Cordy/Cairn#129
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Split out of #105 so it survives that issue closing (the same near-miss as #104's notification gap).
The trap (from #123):
CanReceivetakes groups as a parameter because the recipient is not authenticated — there is no session to read live groups from. Thecmd/cairndwiring passesnilwhen no IdP admin client is configured. So on such an instance, a group-onlyreceiversallow-list matches nobody. Correctly fail-closed, but silently useless — and the failure surfaces on the peer's side asSTATUS_UNKNOWN_RECIPIENT, the worst possible place to debug a local misconfiguration.Fix: in the peering admin panel (Settings → Peering, #120's surface), when saving a peer whose
receivershas groups but no users, and the instance has no IdP admin client: either refuse the save or warn plainly. Warning is probably right — the admin may be about to configure the client — but the text must say this list matches nobody until the admin client exists.Small, self-contained, touches only the Settings panel JS and one server-side capability probe (whether
spaces.Manageris configured is already known tocairndat boot; the panel needs that bit exposed or inferred).User-based lists are unaffected and work in every auth mode.
Shipped in v0.4.8 (PR #139), live on the dogfood.
The implementation turned out bigger than filed, because the receivers allowlist (#123) existed only in the registry:
addPeernever decoded areceiversfield,listPeersnever returned it, the panel had no inputs for it — andpeerRecipientspassednilgroups unconditionally, so a group receivers list matched nobody on every instance, admin client or not. #129's warning alone would have been misleading; the whole path had to be completed.Server:
addPeerdecodes and storesreceivers {users, groups};listPeersreturns each peer's receivers plus a top-levelgroupsLivecapability bit —spacesMgr != nil, i.e. whether the Keycloak admin client (the same service-account client key custody uses) is configured. No new endpoint.peerRecipientsgains agroupshook wired tospaces.Manager.UserGroupswhen the admin client exists: inbound recipients now get real out-of-band group resolution, the completion #123 deferred. Without the client the hook is nil and group lists keep failing closed. Resolution errors degrade to nil (fail closed), never fail open.TestAddPeerRoundTripsReceivers: round trip,groupsLivepresence, a group receiver honoured when groups resolve, and the #129 trap itself — a group-only list matching nobody without resolvable groups.Panel (Settings → Peering):
groupsLiveis false shows exactly the warning this issue asked for: "Saved — but this receivers list matches nobody yet: group membership cannot be resolved without an IdP admin client. Add users, or configure the Keycloak admin client." Warn-not-refuse, as specified — the admin may be about to configure the client. i18n en/de/fr/it.send: zeus321 · receive: staff (group).p.peersoff an unparsedResponse(same class as #136) — latent only because no peer had ever been registered.Note for the dogfood:
cairn-encdoes have the Keycloak admin client configured (storage.encryptioncustody), sogroupsLiveis true there and group-based receiver lists genuinely resolve — the warning will only appear on instances without it.Verified: gofmt/vet clean, full
go test ./...green incl. the new test,node --checkon both script blocks; imagecordy/cairn:v0.4.8(sha256:446d8bc6…) Running 1/1 on the dogfood with/dataon the PVC.