Context

The portal already had a login system, but every account on it had been created by hand, by me. That's fine for a lab only I use — it stops working the moment I actually want outside visitors to be able to request access on their own.

The problem

A public "request access" form is an obvious idea and an obvious abuse surface at the same time. Left unmoderated, it becomes a way to mint junk accounts. And once an account exists, it needs to map onto exactly the right level of access — nothing more — without that mapping logic becoming a maintenance nightmare every time a new self-service item gets added to the catalog.

The solution

A public form collects a request, nothing more — no account is created at that point. A moderation step (mine, for now) turns an approved request into a real account, with a deliberately scoped set of group memberships that control exactly which parts of the site and which catalog items that person can touch. A separate identity system, isolated from the one used for my own internal accounts, is the source of truth for every external visitor — so that even a worst-case compromise of the visitor-facing side never touches anything internal.

A "guided demo" account type — time-boxed, usage-capped — was fully built and tested, then deliberately left switched off. Turning it on for real would give someone a bounded amount of time and quota, but not a bounded amount of network reach, and the network segmentation work needed to actually make that safe is still in progress — it was paused for a while waiting on hardware, and has now resumed, one node at a time (see the companion piece on splitting the network into zones). A capability that looks safe on paper but isn't safe end-to-end doesn't get shipped just because the code is ready.

A bug that would have locked everyone out

Turning on role-based access control is the single riskiest step in a chantier like this — flip it on too early, before every group actually exists, and you can lock yourself out of the admin area along with everyone else. It was sequenced deliberately: confirm the underlying authentication switch works, confirm the service restarts cleanly, and only then flip on the access rules — never in the same breath.

Even sequenced carefully, a real bug slipped through pre-production testing: the access-control check was reading a request path in a form that gets silently rewritten once a route is mounted under a subpath, so every path comparison would have failed — denying everyone, including an administrator. Caught before going live, fixed by reading the untouched, original request path instead.

Alternatives considered

• Creating the account the moment the form is submitted, skipping moderation entirely — rejected: an unmoderated public form that mints real identities is exactly the kind of thing that gets abused.
• One single "has catalog access" flag instead of per-item group membership — rejected: it removes the ability to hand someone exactly one thing without handing them everything.