Auth VM (auth-last1id) — L1 Entry Config Capture¶
Host: auth-last1id · 192.168.1.96 · /opt/auth-last1id
Purpose: Prevent stale-config drift (RealOutcomes OAuth client lesson). Secrets live in BWS Last1.id project only — this doc captures non-secret shape.
DEPLOY GATE (do not skip on next auth-VM touch)¶
| Flag | State |
|---|---|
| Login works today (2026-09-03) | Yes — manual sed applied GOTRUE_URI_ALLOW_LIST on live VM |
| VM reconciled with git template? | No — live compose matches intent but was not applied via apply-gotrue-google-week4.sh |
| Risk on next stack redeploy | Empty or stale allow-list → LastVet partner OAuth handshake breaks (RealOutcomes-500 pattern) |
Required before the next auth-last1id deploy or compose rewrite: run apply-gotrue-google-week4.sh (BWS Google OAuth keys). No action needed while login works and no deploy is planned.
Muster tracker: auth-vm-gotrue-uri-allow-list-reconcile-before-next-deploy (status next).
Authoritative sources (git)¶
| Artifact | Path |
|---|---|
| Compose template | lastvet-gates/scripts/last1-id/setup-auth-stack.sh |
| Apply + reconcile script | lastvet-gates/scripts/last1-id/apply-gotrue-google-week4.sh |
| BWS key names | LAST1_ID_R940_PROD_GOOGLE_OAUTH_CLIENT_ID, LAST1_ID_R940_PROD_GOOGLE_OAUTH_CLIENT_SECRET |
Required GoTrue settings (L1 entry)¶
Google OAuth (.env on VM)¶
GOOGLE_OAUTH_CLIENT_ID=<from BWS — project number MUST NOT be 584962111101>
GOOGLE_OAUTH_CLIENT_SECRET=<from BWS>
GOOGLE_OAUTH_REDIRECT_URI=https://auth.last1.id/auth/v1/callback
Verified live (2026-09-02): client prefix 322031692113 (dedicated Last1 ID GCP project).
Retired (do not restore): 584962111101-s1ov5cudu0p5a3tp2kf3orfridp1refi… (RealOutcomes client — caused wrong Google consent branding).
Partner OAuth redirect allow-list (docker-compose.yml → auth service)¶
GOTRUE_URI_ALLOW_LIST: "https://auth.last1.id/oauth/authorize,https://auth.last1.id/authorize,https://auth.last1.id/dashboard,https://auth.last1.id/onboarding"
Why: After Google sign-in, Supabase/GoTrue must honor redirectTo=/oauth/authorize so LastVet's ASWebAuthenticationSession completes the partner handshake. Empty allow-list → user lands on last1.id dashboard/credentials instead of returning to the app.
VM status (2026-09-02): Ryan applied manually via sed on VM. Repo scripts updated same day — reconcile VM with script on next auth touch.
Reconcile procedure (operator)¶
From workstation with BWS + SSH:
cd lastvet-gates/scripts/last1-id
eval "$(./export-bws-auth-env.sh)" # requires BWS_ACCESS_TOKEN
scp apply-gotrue-google-week4.sh ryan@192.168.1.96:/tmp/
ssh ryan@192.168.1.96 "export LAST1_ID_R940_PROD_GOOGLE_OAUTH_CLIENT_ID='${LAST1_ID_R940_PROD_GOOGLE_OAUTH_CLIENT_ID}' LAST1_ID_R940_PROD_GOOGLE_OAUTH_CLIENT_SECRET='${LAST1_ID_R940_PROD_GOOGLE_OAUTH_CLIENT_SECRET}' && bash /tmp/apply-gotrue-google-week4.sh"
Verify:
curl -s "https://auth.last1.id/auth/v1/authorize?provider=google" \
-o /dev/null -w '%{redirect_url}\n' -L --max-redirs 0 | grep -o 'client_id=[^&]*'
# Must NOT contain 584962111101
What a redeploy would revert (if unchecked)¶
If you redeploy from an old setup-auth-stack.sh without L1 patches |
Effect |
|---|---|
GOTRUE_URI_ALLOW_LIST: "" |
Partner OAuth return-to-LastVet breaks again |
| Old BWS values not loaded | Wrong or missing Google client |
Mitigation: Always run apply-gotrue-google-week4.sh after stack deploy; keep setup-auth-stack.sh in sync with this doc.
Not in scope for L1 entry¶
- SMTP / magic-link email (deferred)
last1.idNode app deploy (separate from GoTrue)- DNS cutover changes