docs(auth): correct the claim that QA could never run Google sign-in #356

2026-09-11T14:49:02-05:00

bermudalamb commented

2026-09-11 14:49:02 -05:00

It can, and it does. Registering the QA callback under Authorized redirect URIs was all it took.

What was wrong

The claim was that qa-redefined-designs.bermudalamb.synology.me could never be registered, because Google requires a redirect URI's host to sit under a domain whose ownership has been proved by DNS, and Synology owns the domain above that one.

It was inferred from #285, where Cloudflare's free tier genuinely cannot be applied to that hostname, and asserted with far more confidence than the inference supported. What was actually established is much narrower: localhost is exempt from the authorized-domain rules, and a domain listed as an authorized domain has to be verified in Search Console. Whether either applied here was never checked.

What it cost

Not harmless. On the strength of it:

QA testing of Google sign-in was documented as blocked behind #313
docker-compose.qa.yml hardcoded its credentials to empty rather than reading the stack
#345 recorded it as a constraint
#332 closed with it written into the summary
a QA deploy was spent discovering otherwise

What changed

The wrong sentences are corrected in place rather than quietly deleted. A document that silently stops saying something teaches nobody why it said it. This is the second time in this feature that a confident inference about somebody else's platform has cost a day, the first being the assumption that a passing local build said anything about another machine.

What replaces it is the thing that was always true and never written plainly: every environment sends a redirect URI derived from its own PUBLIC_URL, and each has to exist verbatim in the console. One table now lists all four:

Environment	Redirect URI
Local, Vite dev server	`http://localhost:5173/api/auth/google/callback`
Local, backend serving a build	`http://localhost:3000/api/auth/google/callback`
QA	`https://qa-redefined-designs.bermudalamb.synology.me/api/auth/google/callback`
Production	`https://redefined-designs.com/api/auth/google/callback`

That includes the localhost:5173 entry local development needs, which Phase 0 omitted — the omission behind an hour of redirect_uri_mismatch before any of this.

The QA compose comment now says which URL to register rather than why it cannot be. The ops document gains the steps QA actually took, in order, with a note on why registering before setting the variables is the order that matters: a button that appears before its callback exists fails at Google, where nothing in the storefront logs explains it.

Testing

Backend tsc clean, the QA compose file still parses, and no file in the tree still claims the hostname is unusable.

🤖 Generated with Claude Code

It can, and it does. Registering the QA callback under Authorized redirect URIs was all it took. ## What was wrong The claim was that `qa-redefined-designs.bermudalamb.synology.me` could **never** be registered, because Google requires a redirect URI's host to sit under a domain whose ownership has been proved by DNS, and Synology owns the domain above that one. It was inferred from #285, where Cloudflare's free tier genuinely cannot be applied to that hostname, and asserted with far more confidence than the inference supported. What was actually established is much narrower: `localhost` is exempt from the authorized-domain rules, and a domain listed as an authorized domain has to be verified in Search Console. Whether either applied here was never checked. ## What it cost Not harmless. On the strength of it: - QA testing of Google sign-in was documented as blocked behind #313 - `docker-compose.qa.yml` hardcoded its credentials to empty rather than reading the stack - #345 recorded it as a constraint - #332 closed with it written into the summary - a QA deploy was spent discovering otherwise ## What changed The wrong sentences are **corrected in place rather than quietly deleted**. A document that silently stops saying something teaches nobody why it said it. This is the second time in this feature that a confident inference about somebody else's platform has cost a day, the first being the assumption that a passing local build said anything about another machine. What replaces it is the thing that was always true and never written plainly: every environment sends a redirect URI derived from its own `PUBLIC_URL`, and each has to exist verbatim in the console. One table now lists all four: | Environment | Redirect URI | |---|---| | Local, Vite dev server | `http://localhost:5173/api/auth/google/callback` | | Local, backend serving a build | `http://localhost:3000/api/auth/google/callback` | | QA | `https://qa-redefined-designs.bermudalamb.synology.me/api/auth/google/callback` | | Production | `https://redefined-designs.com/api/auth/google/callback` | That includes the `localhost:5173` entry local development needs, which Phase 0 omitted — the omission behind an hour of `redirect_uri_mismatch` before any of this. The QA compose comment now says which URL to register rather than why it cannot be. The ops document gains the steps QA actually took, in order, with a note on why registering before setting the variables is the order that matters: a button that appears before its callback exists fails at Google, where nothing in the storefront logs explains it. ## Testing Backend `tsc` clean, the QA compose file still parses, and no file in the tree still claims the hostname is unusable. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

bermudalamb added 1 commit 2026-09-11 14:49:03 -05:00

docs(auth): correct the claim that QA could never run Google sign-in

SonarQube Analysis / sonarqube (pull_request) Failing after 28m29s

Details

Linting / lint (pull_request) Successful in 3m44s

Details

f5a29127fb

It can, and it does. Registering the QA callback under Authorized redirect URIs was all it took.

The claim was that qa-redefined-designs.bermudalamb.synology.me could never be registered, because Google requires a redirect URI's host to sit under a domain whose ownership has been proved by DNS, and Synology owns the domain above that one. It was inferred from #285, where Cloudflare's free tier genuinely cannot be applied to that hostname, and asserted with far more confidence than the inference supported. What was actually established is narrower: localhost is exempt from the authorized-domain rules, and a domain listed as an authorized domain has to be verified in Search Console. Whether either applied here was never checked.

It was not a harmless error. On the strength of it, QA testing of this feature was documented as blocked behind #313, the QA compose file hardcoded its credentials to empty rather than reading the stack, #345 recorded it as a constraint, and #332 closed with it written into the summary. A QA deploy was spent on it.

So the correction is left in place rather than the wrong sentences quietly deleted. A document that silently stops saying something teaches nobody why it said it, and this is the second time in this feature that a confident inference about somebody else's platform has cost a day — the first being the assumption that a passing local build said anything about another machine.

What replaces it is the thing that was always true and never written down plainly: every environment sends a redirect URI derived from its own PUBLIC_URL, and each one has to exist verbatim in the console. There is now one table listing all four, including the localhost:5173 entry that local development needs and that Phase 0 originally omitted — the omission that cost an hour of redirect_uri_mismatch before any of this.

The QA compose comment now says which URL to register rather than why it cannot be. The ops document gains the steps QA actually took, in order, with a note on why registering before setting the variables is the order that matters: a button that appears before its callback exists fails at Google, where nothing in the storefront logs explains it.

Verified: backend tsc clean, the QA compose file still parses, and no file in the tree still claims the hostname is unusable.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>