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

Closed
opened 2026-09-10 08:13:21 -05:00 by bermudalamb · 1 comment
Owner

Part of #332. Phase 6 of six. Depends on #343 and #344.

The first phase a customer can see. AuthForm.tsx is the single sign-in implementation rendered by both the route modal and the cart prompt, so the button goes in one place and appears everywhere.

Scope

  • Put it where the passkey button went — below the password form, behind the same divider. Passwords are how existing customers sign in; this is the alternative, and promoting it above demotes the path that works for everyone. Absent rather than disabled when the credentials are unset, using the enabled flag from #340.
  • Follow Google's branding rules. The wordmark, colours and minimum sizes are specified, and a hand-drawn approximation is a compliance problem rather than a style choice. Take the asset from Google's identity guidelines and inline it.
  • Return the customer where they were. The cart prompt resumes the interrupted action and the route modal closes back to the page behind it. An OAuth redirect leaves the application entirely, so the return path is carried in the state cookie, not the URL.

The cutover, which belongs in #313

Google refuses a redirect URI whose host is not under a verified authorized domain, and qa-redefined-designs.bermudalamb.synology.me cannot be authorized — Synology owns the registrable domain above it. Same wall as #285.

So this feature is built and exercised on localhost only, and QA cannot see it until QA moves onto a subdomain of the real domain. The Search Console property already covers qa.redefined-designs.com.

At the cutover:

  1. Point QA at qa.redefined-designs.com and set its PUBLIC_URL to match. No code change — the redirect URI derives from that variable.
  2. Add https://qa.redefined-designs.com/api/auth/google/callback in Clients.
  3. In Audience, move the publishing status from Testing to In production, once the domain resolves so the home page and privacy links actually answer.

Leave it in Testing and every customer not on the test-user list is refused on Google's own page, with nothing in the storefront logs to explain it.

Smoke test in production

The consent screen, the redirect and the domain are all environment-specific, so QA proves the flow but not the configuration. One real sign-in after the cutover with a Google account never used on the site, then a second to confirm it reaches the same customer.

Done when

A customer can sign in with Google from both the login route and the cart prompt, arrives at the same session a password login produces, returns to the page they came from, and a returning customer reaches the same account rather than a second one.

Part of #332. Phase 6 of six. Depends on #343 and #344. The first phase a customer can see. `AuthForm.tsx` is the single sign-in implementation rendered by both the route modal and the cart prompt, so the button goes in one place and appears everywhere. ## Scope - **Put it where the passkey button went** — below the password form, behind the same divider. Passwords are how existing customers sign in; this is the alternative, and promoting it above demotes the path that works for everyone. Absent rather than disabled when the credentials are unset, using the `enabled` flag from #340. - **Follow Google's branding rules.** The wordmark, colours and minimum sizes are specified, and a hand-drawn approximation is a compliance problem rather than a style choice. Take the asset from Google's identity guidelines and inline it. - **Return the customer where they were.** The cart prompt resumes the interrupted action and the route modal closes back to the page behind it. An OAuth redirect leaves the application entirely, so the return path is carried in the state cookie, not the URL. ## The cutover, which belongs in #313 Google refuses a redirect URI whose host is not under a verified authorized domain, and `qa-redefined-designs.bermudalamb.synology.me` cannot be authorized — Synology owns the registrable domain above it. Same wall as #285. **So this feature is built and exercised on `localhost` only, and QA cannot see it until QA moves onto a subdomain of the real domain.** The Search Console property already covers `qa.redefined-designs.com`. At the cutover: 1. Point QA at `qa.redefined-designs.com` and set its `PUBLIC_URL` to match. No code change — the redirect URI derives from that variable. 2. Add `https://qa.redefined-designs.com/api/auth/google/callback` in Clients. 3. In Audience, move the publishing status from Testing to **In production**, once the domain resolves so the home page and privacy links actually answer. Leave it in Testing and every customer not on the test-user list is refused on Google's own page, with nothing in the storefront logs to explain it. ## Smoke test in production The consent screen, the redirect and the domain are all environment-specific, so QA proves the flow but not the configuration. One real sign-in after the cutover with a Google account never used on the site, then a second to confirm it reaches the same customer. ## Done when A customer can sign in with Google from both the login route and the cart prompt, arrives at the same session a password login produces, returns to the page they came from, and a returning customer reaches the same account rather than a second one.
Author
Owner

Correction: QA can run Google sign-in, and does

This issue states that qa-redefined-designs.bermudalamb.synology.me cannot carry a redirect URI, because Google requires the host to sit under a domain whose ownership is proved by DNS and Synology owns the domain above it.

That is wrong. Registering the URI works. QA has been running Google sign-in since.

The claim was inferred from #285, where Cloudflare's free tier genuinely cannot be applied to that hostname, and stated as fact without being checked. What was actually established is narrower: localhost is exempt from the authorized-domain requirement, and a domain listed under Authorized domains has to be verified in Search Console. Whether either applied here was never tested.

What it changed

The cutover section above is wrong about dependency, not about content. Moving QA to qa.redefined-designs.com is still worth doing, and the steps are still right, but it is not what unblocks this feature. It unblocks nothing here — the hostname is changing anyway, and a redirect URI naming the old one stops working when it does.

So the QA entry in that list is a step for #313 rather than a prerequisite for this.

What is actually required, per environment

Each of these has to exist verbatim under Authorized redirect URIs:

http://localhost:5173/api/auth/google/callback
http://localhost:3000/api/auth/google/callback
https://qa-redefined-designs.bermudalamb.synology.me/api/auth/google/callback
https://redefined-designs.com/api/auth/google/callback

The first is the one local development uses, since the Vite dev server on 5173 is where the app is browsed. Its omission from the original setup cost an hour of redirect_uri_mismatch.

Corrected in #356, along with docs/ops/google-sign-in.md, the QA compose comment, and the config module.

## Correction: QA can run Google sign-in, and does This issue states that `qa-redefined-designs.bermudalamb.synology.me` cannot carry a redirect URI, because Google requires the host to sit under a domain whose ownership is proved by DNS and Synology owns the domain above it. **That is wrong.** Registering the URI works. QA has been running Google sign-in since. The claim was inferred from #285, where Cloudflare's free tier genuinely cannot be applied to that hostname, and stated as fact without being checked. What was actually established is narrower: `localhost` is exempt from the authorized-domain requirement, and a domain listed under Authorized domains has to be verified in Search Console. Whether either applied here was never tested. ### What it changed The **cutover section above is wrong about dependency, not about content.** Moving QA to `qa.redefined-designs.com` is still worth doing, and the steps are still right, but it is not what unblocks this feature. It unblocks nothing here — the hostname is changing anyway, and a redirect URI naming the old one stops working when it does. So the QA entry in that list is a step for #313 rather than a prerequisite for this. ### What is actually required, per environment Each of these has to exist verbatim under Authorized redirect URIs: ``` http://localhost:5173/api/auth/google/callback http://localhost:3000/api/auth/google/callback https://qa-redefined-designs.bermudalamb.synology.me/api/auth/google/callback https://redefined-designs.com/api/auth/google/callback ``` The first is the one local development uses, since the Vite dev server on 5173 is where the app is browsed. Its omission from the original setup cost an hour of `redirect_uri_mismatch`. Corrected in #356, along with `docs/ops/google-sign-in.md`, the QA compose comment, and the config module.
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#345