- Ya
- 12 Mei 2026, 05:08 UTC
- Mwandishi
- kamo
- Ahadi ya
- d843675
registrableDomainFromAlias strips any multi-label subdomain (e.g. "gnosia.demo.kamocrm.com") down to its eTLD+1 ("kamocrm.com"). That was fine for the API base / login host / OAuth credential lookup — those are intentionally shared platform-wide — but it was ALSO being used as the path segment for **************** The Java endpoint then matched the eTLD+1 against the platform-owner org's row and returned KamoCRM Inc. data for anyone hitting a subdomain tenant (gnosia, abcmortgage, etc.). The user-facing symptom: child-org owners on their own subdomain saw the parent org's title/theme/feature list and tripped the parent org's right gates on pages like /settings/account, which checked CONFIGURE_SYSTEM against a session resolved against the wrong org. SecurityService.findByDomain handles both the full FQDN form ("gnosia.demo.kamocrm.com" → GNosia's primary row directly) and the "label.parent" composite ("internal.kamocrm.com" → KamoCRM's "internal" child row joined to the parent row), so passing the unstripped aliasDomain resolves correctly for every tenant. Other usages of registrableDomainFromAlias (API base, login base, OAuth credentials) are unchanged — they correctly share platform infrastructure.