mirror of
https://github.com/hanzoai/id.git
synced 2026-10-16 18:38:15 +00:00
zooqueenandHanzo Dev
bc3e47cb22
Reported from a phone: fill in email + password on hanzo.id/signup, press
Create account, get "the application does not allow to sign up new account".
Not reproducible on demand, which is the tell.
resolveOrg spreads the runtime catalog OVER the built-in table, and for
hanzo.id the two named DIFFERENT applications:
built-in DEFAULT_TENANTS hanzo-id enableSignUp false
catalog /config.json hanzo-console enableSignUp true
So the answer to "can this person create an account" depended on whether a
second network fetch arrived before the form was submitted. When it did, signup
worked -- which is why it looks fine from a desk. When it did not, the page
still rendered a full form (the fallback app permits password login, just not
registration) and IAM refused the POST. On a phone a dropped request is
ordinary, so that is where it showed up.
Confirmed against prod by replaying the exact POST the SPA makes:
clientId=hanzo-console application=hanzo-console -> past the gate
clientId=hanzo-console application=hanzo-id -> "the application does
not allow to sign up
new account"
The second line is the customer's screenshot, reproduced.
lux.id had the same divergence (lux-id vs lux-cloud); both are false there, so
it was latent rather than live. Fixed with hanzo's -- the invariant is one host
one app, not "the currently harmful ones".
The fix is NOT to make the fallback survivable. This table is a fallback for a
failed /config.json, not a second opinion, so the answer is that there is only
one answer per host. org.test.ts now asserts that resolving a host WITH and
WITHOUT the catalog yields the same clientId; reverting org.ts reproduces the
failure ("hanzo.id fallback", 1 failed | 15 passed) and restoring it passes,
so the guard is known to bite. 171/171, typecheck clean.
Co-authored-by: Hanzo Dev <[email protected]>