fix: carry the Google and Web3Auth client IDs separately - #1272
Conversation
`subVerifierDetails.clientId` is the provider's client ID, not the Web3Auth project's, so every Google sign-in sent Google an identifier it has never issued and got back `401 invalid_client`. `loginEnv` now reads `VITE_GOOGLE_CLIENT_ID` alongside the Web3Auth pair and returns them under names that cannot be swapped, and the session routes each sub-verifier to its own registration: the Google connection takes the Google Cloud OAuth client ID, the Torus-hosted email one the Web3Auth project's. The variable was already set at every staging deploy site and read nowhere. Adding it to `LOGIN_ENV` puts it behind the same build gate as the rest, so a missing one names itself instead of surfacing a provider error.
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Absent and whitespace-only are one state to `configured`, so asserting them separately said the same thing twice.
|
Closing unmerged — superseded by #1273, which carries both of these commits and now closes #1256 itself. The env plumbing here is load-bearing and survives untouched: With no staging environment yet, landing an intermediate fix to a code path the next PR deletes bought nothing, and the surviving half reaches Generated by Claude Code |
Closes #1256. Part of #1253.
What was wrong
subVerifierDetails.clientIdis the provider's client ID. The app was spending one value on two unrelated things:VITE_WEB3AUTH_CLIENT_IDcorrectly named the Web3Auth project to theWeb3AuthMPCCoreKitconstructor, and then that same string was handed to the Google sub-verifier. Google has never issued it, so every Google sign-in ended at401 invalid_clientbefore Web3Auth was involved.The right value was never absent from the deployment —
VITE_GOOGLE_CLIENT_IDis passed at every staging build site indeploy-staging.ymlanddesktop-staging-release.yml. It survived the rewrite; its reader did not.What changed
loginEnvnow returns{ web3AuthClientId, googleClientId, verifier }. The old shape returnedclientId, a name that invited exactly this substitution — neither field can now be picked by accident.VITE_GOOGLE_CLIENT_IDjoinsLOGIN_ENV, so it is declared invite-env.d.ts, named bymissingLoginEnv, and — throughDEPLOY_ENV— fails thedeployEnvGatebuild plugin on a staging or production build that omits it. A deployed build can no longer ship a Google button that cannot work.apps/web/.env.examplenow lists all three and states plainly that the two client IDs are separate registrations and not interchangeable — the template previously implied one client ID was the whole story, which is how this recurs.email_passwordlessIt takes the Web3Auth project client ID, not Google's. That sub-verifier is Torus-hosted: there is no third-party OAuth client behind it, and the connection is registered under the Web3Auth project itself. Sending Google's ID there would break email sign-in in the same way this PR fixes Google. Worth a second pair of eyes against the verifier's actual dashboard configuration before merge.
Tests
coreKit.test.tscapturessubVerifierDetailsoff the substituted SDK and asserts the Google connection receives the Google OAuth client ID, the email connection receives the Web3Auth one, and the constructor receives the Web3Auth one.config.test.tsasserts the two IDs stay apart throughloginEnv, and that a build missingVITE_GOOGLE_CLIENT_IDthrows naming it — absent, blank, and whitespace-only alike — rather than surfacing a provider error nobody can act on.missingDeployEnvcovers the red-build half.Ran:
pnpm --filter @cipherbox/web test(32 files, 295 tests, includestsc -b),pnpm lint,pnpm lint:md,pnpm lint:tracker-refs— all green.Needs human verification
No dev server or configured verifier exists in this environment, so the runtime path is unverified: a real Google sign-in against a verifier whose Google sub-verifier is registered with the Google Cloud OAuth client ID in
GOOGLE_CLIENT_ID, plus one email sign-in to confirm that connection still authenticates on the Web3Auth project ID.Scope
Only the client-ID plumbing. The Core Kit login architecture is untouched —
loginWithOAuthis replaced wholesale by a separate PR.Note
Carry Google and Web3Auth client IDs separately for OAuth sub-verifiers
clientIdinto two:VITE_GOOGLE_CLIENT_ID(used by Google OAuth sub-verifier) andVITE_WEB3AUTH_CLIENT_ID(used by the email passwordless sub-verifier and SDK init). Previously both sub-verifiers shared one client ID.config.tsto require and return both IDs fromloginEnv(), throwing if either is missing or blank.coreKit.tsto accept aSubVerifierClientIdsmap and select the correct ID per login method.VITE_GOOGLE_CLIENT_IDis now a required environment variable; deployments missing it will throw at session creation time.Macroscope summarized 9f87e8d. (Automatic summaries will resume when PR exits draft mode or review begins).