- Ya
- 24 Agosti 2026, 20:56 UTC
- Mwandishi
- Kamo
- Ahadi ya
- e91fc9f
OrgHostResolver.resolveByDomain filtered on od.is_dns_verified = TRUE, so a domain row that existed but had not finished verifying resolved to nothing and login refused with "Organization and/or organization provider was not found." DNS verification records whether traffic can be served on a host yet -- a fact about building URLs -- not whether a member may authenticate, and using it as an access predicate is what made DNS setup a prerequisite for using the product. Against the live estate this predicate was holding 13 of the 23 active organizations out at the auth layer. Every one of them has a domain row already; none is DNS-verified, and each is its own security provider, so neither the domain path nor the alias path resolved for any of them. Checked before removing it: no two active organizations claim the same top-level domain, so nothing becomes ambiguous. The threat model is unchanged -- reaching a host still requires controlling DNS for it, and enforceUniqueness still refuses a second claim on the same FQDN. Also adds OrgResolutionService, which answers "which organization is this" in one place. Three implementations disagreed about it: this one required DNS verification, **************** checked nothing, and **************** checked neither active flag -- so the answer depended on which a caller reached. It resolves by id, by public ref (digits are ids and never fall through to the alias lookup, so the namespaces cannot overlap silently), or by host. 875 tests pass.