mirror of
https://github.com/hanzoai/id.git
synced 2026-10-16 18:38:15 +00:00
zeekay
457a6c1c45
Wallet sign-in was unreachable on hanzo.id. The entry was built out of the
application's provider LIST, and IAM no longer publishes a web3 row there —
three independent reasons, none of which will change:
- the seeded provider-web3 record is category "OAuth" with the unexpanded
clientId ${IAM_WEB3_CLIENT_ID}, so IAM's own `offerable` strips it before
the descriptor leaves the server;
- all 80 applications that link it set canSignIn:false;
- IAM deliberately MOVED the capability off the row (pkg/schema/wallet.go:
the row "names a third-party library this build does not import") and
answers it from schema.WalletChains() on /v1/iam/auth/methods.
Live get-app-login for hanzo-console returns exactly [provider-github,
provider-google]; a headless browser on hanzo.id/login found no
data-provider="web3" anywhere — while /v1/iam/web3/nonce answered a real
CAIP-122 challenge for evm, solana AND bitcoin. So a wallet-only account,
provisioned by /v1/iam/web3/verify and holding no password, had no way in.
The screen now asks the question IAM actually answers. Two reads, because
they are two different questions and conflating them is what broke this:
get-app-login says what this APPLICATION offers, auth/methods says what this
BINARY can do. Neither read can remove the other's buttons.
ENABLED_WALLET_CHAINS is deleted. It was a copy of a server policy ("TON /
XRP / Bitcoin verifiers are still stubs") kept in the browser, where it could
only ever drift — and had: IAM accepts seven families, this bundle can sign
five, and the copy offered two. What is offered is now the intersection of
what IAM will verify and what @hanzo/id-connect has a connector for, so the
screen can neither offer a chain the verifier refuses nor hide one it accepts.
PROVIDER_ORDER stays the ONE order for the whole strip, wallet included.
The capability read goes through the client like every other IAM read, so
there is one fetch seam rather than a module reaching for global fetch.
And the runner can finally hold any of this: it collected only *.test.ts in a
`node` environment with no document, so WHICH method renders WHEN was
unverifiable — a whole sign-in method went missing with `pnpm tc` and
`pnpm test` both green, and the one page-level test reads Login.tsx as TEXT
and matches regexes against it. *.test.tsx now runs in a DOM; the four new
mounted tests fail against the provider-row gate and pass against this.
21 lines
1.1 KiB
TypeScript
21 lines
1.1 KiB
TypeScript
import { defineConfig } from 'vitest/config'
|
|
|
|
// Single test runner for the whole monorepo. Every `*.test.ts` and `*.test.tsx`
|
|
// under any package's `src/` runs here — the connect crypto/connector suites
|
|
// (vitest describe/it/expect), the auth / shared / onboarding suites (bare
|
|
// `test()` + node:assert), and the component suites that mount a form and read the
|
|
// DOM. One config, one `pnpm test`, one way.
|
|
//
|
|
// A DOM for everything, rather than per-file annotations. The login surface's whole
|
|
// claim is WHICH sign-in method renders WHEN, and that was unverifiable: no .tsx
|
|
// pattern was collected and the environment had no document, so the one page-level
|
|
// test read Login.tsx as TEXT and matched regexes against it — green with the
|
|
// component fully broken, red on an innocuous rename. Everything else here is
|
|
// pure and does not care that a window exists.
|
|
export default defineConfig({
|
|
test: {
|
|
include: ['pkgs/**/src/**/*.test.ts', 'pkgs/**/src/**/*.test.tsx', 'apps/**/src/**/*.test.ts', 'apps/**/src/**/*.test.tsx'],
|
|
environment: 'happy-dom',
|
|
},
|
|
})
|