Skip to content

docs: operator steps for sign-in by code and Google, and the env to deploy them - #293

Merged
oratis merged 1 commit into
feat/auth-google-clientsfrom
feat/auth-docs
Jul 24, 2026
Merged

docs: operator steps for sign-in by code and Google, and the env to deploy them#293
oratis merged 1 commit into
feat/auth-google-clientsfrom
feat/auth-docs

Conversation

@oratis

@oratis oratis commented Jul 23, 2026

Copy link
Copy Markdown
Owner

Stacked on #292. Last of the chain.

One real bug, not just docs

deploy/deploy.sh builds an explicit env allowlist, so LISA_GOOGLE_WEB_CLIENT_ID / LISA_GOOGLE_IOS_CLIENT_ID would have been dropped silently — a deploy that reports success and leaves the Google button invisible with no error anywhere. Both are now passed through, and the header documents the sign-in-by-code dependency on RESEND_API_KEY (without it codes only reach the server log, so nobody can complete a sign-in).

Runbook

  • Phase 8 — verify the Resend sending domain, with a curl self-check that distinguishes "accepted" from "actually sent".
  • Phase 9 — GCP OAuth consent screen + the two client ids (Web needs only a JS origin; iOS needs only the bundle id — Google derives the reversed-client-id redirect itself, and the app registers no URL scheme), plus the redeploy command carrying both new env groups and the still-missing Apple Services ID.
  • Phase 10 — shipping a build. Deliberately does not prescribe a version bump: 1.1 hasn't been submitted yet, so these changes most likely fold into that same submission rather than becoming 1.2 — but that depends on ASC state the repo can't see, so the runbook branches on it instead of guessing. Includes the Review Notes sentence to add.

Plan doc marked implemented with the PR chain and the two incidental fixes found along the way.

npm test → 1173 green; bash -n deploy/deploy.sh clean, and I checked the new allowlist lines actually emit the pairs.

🤖 Generated with Claude Code

…eploy them

deploy.sh passes an explicit env allowlist, so the two Google client ids
would have been dropped silently — a deploy that looked fine and left the
button invisible. Added, with the sign-in-by-code dependency on
RESEND_API_KEY spelled out in the header (no key ⇒ codes only reach the
server log ⇒ nobody can sign in).

Runbook gains Phase 8 (verify the Resend sending domain, with a curl
self-check), Phase 9 (GCP OAuth consent + the Web and iOS client ids,
plus the redeploy command with both new env groups) and Phase 10 (ship a
build — deliberately NOT prescribing a version bump, since whether this
folds into 1.1 or becomes 1.2 depends on ASC state the repo can't see).

Plan doc marked implemented with the PR chain.

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

oratis commented Jul 24, 2026

Copy link
Copy Markdown
Owner Author

Docs + a genuine deploy fix. Ready to merge.

  • Real bug fixed: deploy/deploy.sh's explicit env allowlist was silently dropping LISA_GOOGLE_WEB_CLIENT_ID / LISA_GOOGLE_IOS_CLIENT_ID — a "successful" deploy with an invisible Google button and no error anywhere. Passthrough added (deploy.sh:71-72). Good catch documenting the RESEND_API_KEY hard-dependency too (without it OTP codes only reach the server log).
  • No secret leakage: scanned the whole diff — every credential is a placeholder; no "disable TLS", no plaintext secret in the examples. The curl self-checks only POST an email to the public OTP endpoint.
  • Runbook accurately branches on ASC state for the version bump and keeps the demo account password-based.

@oratis
oratis merged commit 33697b9 into feat/auth-google-clients Jul 24, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant