- Shipped
- September 2, 2026 at 7:27 PM UTC
- Author
- Kamo
- Commit
- 02f0fd7
A member who signed in on login.kamocrm.com, picked a workspace from the chooser, and landed inside it — on internal.kamocrm.com, wearing the platform's hostname rather than the one their organization paid for. Both sign-in paths derived the destination from the REQUEST hostname alone, swapping the leading label for "internal". That hostname answers "where was the password typed", never "where does this workspace live": login.<apex> is the sign-in screen for every organization without a host of its own, so on the shared host it cannot distinguish between the workspaces on offer. Nothing on the sign-in path ever asked the CHOSEN organization for its domain — the enter-as path had resolved this from the org all along. Resolved in SignInCompletionService, the one gate both paths already share, so this cannot go missing from one of them. The request-derived host stays as the fallback, which is what every organization without a finished domain of its own keeps using — unchanged behaviour for most of the estate. Three conditions on the domain row, all load-bearing: parent_id IS NULL an alias row stores a bare label (internal, api), which is not a hostname ownership_verified several organizations may NAME the same domain; only the one that proved DNS control receives its traffic, and that is the row findAllByVerifiedDomain resolves a host back to. Routing on an unverified row would hand a member to a host that resolves to somebody else's organization ssl_confirmed a merely CONFIGURED domain is not a host you can open; a missing certificate gives a browser interstitial, and the one-time key in the URL is spent either way The tie-break and the registrable filter come from OrgDomains.preferred, so this agrees with every other hostname decision on the platform. That filter is also what drops localhost — a real, active, verified, ssl-confirmed root row on the platform's own organization, and not a hostname anyone can open. Deliberately NOT requiring the `internal` alias child row: the organizations this most affects carry only the root domain, and internal.<domain> is provisioned in DNS and certificates independently of that row. A null host is returned unchanged. A caller that named none is saying it IS the workspace origin, and substituting a production hostname there would send a local sign-in across the internet. Checked against production rows and hosts: optionone.com resolves to internal.optionone.com (live, valid per-FQDN certificate); an organization that typed a domain it never verified keeps internal.kamocrm.com; the platform org resolves to internal.kamocrm.com as before; and all nine other organizations holding a verified domain serve a valid certificate on their internal host. The cross-apex hop is safe: kamo-internal's /validate spends the one-time key against its own origin and keeps the session in per-tab sessionStorage, so the cookie kamo-login sets on the sign-in origin was never what carried it.