Google 1: groundwork — nullable password hash, identities table, config #340

New Issue

2026-09-10T08:12:26-05:00

bermudalamb commented

2026-09-10 08:12:26 -05:00

Part of #332. Phase 1 of six.

Nothing user-visible. The schema change and the configuration land on their own so the widest-reaching edit can be reviewed for what it is.

Scope

Make customers.password_hash nullable, and audit what assumed it was not. Three sites in routes/customers.ts compare against it with bcrypt: login, change password, and the email change. Each must first ask whether there is anything to compare.
Add customer_identities — provider, provider subject, customer id, created and last used. Unique across (provider, provider_sub), never on the subject alone. Keyed on the provider's stable subject and never the email.
Update the schema mirror and test reset lists. The Kysely schema file, REQUIRED_TABLES, the truncate statement, and the table count asserted by the schema-loss test all move together.
Derive the redirect URI from PUBLIC_URL, in a module shaped like passkeys/relyingParty.ts, exposing an enabled flag so Google sign-in is absent rather than broken when the credentials are unset.
Add GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET to environment validation, both-or-neither as a warning, following the SMTP pair.

A correction to #332

That issue lists account deletion as confirming with the password. It does not. DELETE /api/customers/me takes no password, and the confirmation is an antd modal in the account page. Deletion needs no change here.

Done when

Migrations run up and down cleanly, the schema mirror test passes, and the backend boots with the credentials set, unset and half-set, saying something sensible in each case.

Part of #332. Phase 1 of six. Nothing user-visible. The schema change and the configuration land on their own so the widest-reaching edit can be reviewed for what it is. ## Scope - **Make `customers.password_hash` nullable**, and audit what assumed it was not. Three sites in `routes/customers.ts` compare against it with bcrypt: login, change password, and the email change. Each must first ask whether there is anything to compare. - **Add `customer_identities`** — provider, provider subject, customer id, created and last used. Unique across `(provider, provider_sub)`, never on the subject alone. Keyed on the provider's stable subject and **never the email**. - **Update the schema mirror and test reset lists.** The Kysely schema file, `REQUIRED_TABLES`, the truncate statement, and the table count asserted by the schema-loss test all move together. - **Derive the redirect URI from `PUBLIC_URL`**, in a module shaped like `passkeys/relyingParty.ts`, exposing an `enabled` flag so Google sign-in is absent rather than broken when the credentials are unset. - **Add `GOOGLE_CLIENT_ID` and `GOOGLE_CLIENT_SECRET` to environment validation**, both-or-neither as a warning, following the SMTP pair. ## A correction to #332 That issue lists account deletion as confirming with the password. **It does not.** `DELETE /api/customers/me` takes no password, and the confirmation is an antd modal in the account page. Deletion needs no change here. ## Done when Migrations run up and down cleanly, the schema mirror test passes, and the backend boots with the credentials set, unset and half-set, saying something sensible in each case.

bermudalamb referenced this issue

2026-09-10 08:12:38 -05:00

Google 2: the OAuth round trip #341

bermudalamb referenced this issue

2026-09-10 08:13:21 -05:00

Google 6: the button, and the domain cutover #345

bermudalamb referenced this issue from a commit

2026-09-10 08:19:05 -05:00

feat(auth): groundwork for signing in with Google (#340)

bermudalamb referenced a pull request that will close this issue

2026-09-10 08:19:23 -05:00

feat(auth): groundwork for signing in with Google (#340) #346