Adopt the portal owner on attach, rather than demanding a re-enrolment

An installation enrolled before per-user mapping has nobody mapped, and
fail-closed means its owner is refused. Re-enrolling fixes it and can only
be done from the machine's own network, which is the wrong thing to require
of a machine whose only route in is the portal.

The hub names the owner in the handshake now, and this takes it: if the
enrolling account has no portal identity and nobody else holds that one, it
is written once and every later attach is a no-op. A mapping somebody else
holds is never moved - enrolment was told who that is, and this is only a
repair. A failure to write one does not drop the link.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-21 12:07:43 +02:00
co-authored by Claude Opus 5
parent c27ed98cb8
commit 000c5abf91
3 changed files with 81 additions and 1 deletions
+4 -1
View File
@@ -339,7 +339,10 @@ Shares components with the admin view. See `docs/architecture/structure.canvas`
the revocation, immediate even against a credential already in flight and
even when the portal cannot be reached to be told. The hub's `_authorize`
grew one member lookup beside the owner comparison, which is the only
thing that changed about the tunnel
thing that changed about the tunnel. Enrolments made before the mapping
existed adopt it from the handshake — the hub names the owner in its
welcome frame — because the alternative was locking an owner out of a
machine they could only have fixed by standing in front of it
## Phase 5 — Website and docs