- Ya
- 5 Septemba 2026, 01:26 UTC
- Mwandishi
- Kamo
- Ahadi ya
- a729435
Such a host could sign in until now. It fell through to the workspace-choice path and succeeded on membership alone, which made it a door where none of the tenant's own controls applied: access rules and geo blocks are per-organization, so decide(ip, host) could only ever answer "allowed — no organization owns this host". Nothing was bypassed outright, because membership was still proven and completeSignIn re-checks the rules once a workspace is chosen. But the credential check itself sat behind no tenant policy at all, reachable by pointing any DNS name at the ingress, and the lockout ladder added alongside it had no blocklist to escalate into and counted under a synthetic tenant. Refused before the credentials are read and before the lockout gate. Order is half the point: an unknown host is not a wrong password, so counting it would walk a legitimate user toward a lockout over an operator's DNS mistake, and refusing here means the synthetic-tenant counters are never created at all. Said plainly rather than behind the generic credential refusal. Which hosts this platform answers on is not a secret — Traefik already routes by it — and an operator bringing up a new tenant domain who is told "wrong password" will spend the afternoon resetting one. Two carve-outs, both deliberate: localhost. OrgResolutionService.byHost excludes it explicitly, so it can never name an organization and the gate would otherwise make local development impossible. It is decided from the HOST, mirroring that existing carve-out, NOT from "the caller's address is not public" — every request inside the cluster looks that way, so the day X-Forwarded-For forwarding breaks in production that version of the test would switch the gate off across the fleet. Loopback literals only; a bare service name is not exempt. A kill switch, **************** shipping ON. If a domain-table problem ever stops legitimate hosts resolving, sign-in has to be reopenable without a redeploy — and reopening restores the old path exactly rather than a third behaviour. An exempt host must keep DEFERRING to workspace choice, not merely get past the gate. Sending it down the host-resolved path instead breaks it more quietly: authenticateUser's three-argument form refuses without a resolved FQDN, so "unknown host" would have arrived dressed as a wrong password. That was a real defect in the first cut of this change, caught by asking what localhost does next.