Adds scripts/smoke-test.sh — found on the actual first deployment that /api/v1/healthz proves nothing about whether login works, because the session cookie is Secure in production and a plain-HTTP test (an IP, a bare port) silently drops it. Login returns 200; the very next request looks unauthenticated; from a browser it looks exactly like "logged in, bounced back to the login screen," with no visible error. That happened for real this session.
What it does
Runs the actual round trip a browser does: login, confirm a session cookie was stored (not just sent — curl won't store a Secure cookie from a non-HTTPS response either, matching real browser behavior), then an authenticated follow-up request confirming it succeeds and returns the right account.
How this was verified
Ran it for real against the live deployment before committing it, both directions:
Against a throwaway account, over plain HTTP, against a container actually running VELODROME_ENVIRONMENT=production → got the expected FAIL, with the diagnostic correctly pointing at the Secure-cookie mismatch (this is the literal bug that just happened).
Same account/URL once the container's environment was development (inadvertently, from a manual recreate) → got PASS, correctly reflecting that development doesn't set Secure.
Test accounts created for this were cleaned up afterward (direct SQL delete via the running container — there's no CLI for this yet, matches D18's scope).
Docs
deploy/README.md gets a new section recommending this as the real post-deploy check, replacing "hit /healthz and eyeball it" for anything involving auth — pointed at the real public URL, not an IP, since that's the only way this test means anything.
Adds `scripts/smoke-test.sh` — found on the actual first deployment that `/api/v1/healthz` proves nothing about whether login works, because the session cookie is `Secure` in production and a plain-HTTP test (an IP, a bare port) silently drops it. Login returns 200; the very next request looks unauthenticated; from a browser it looks exactly like "logged in, bounced back to the login screen," with no visible error. That happened for real this session.
## What it does
Runs the actual round trip a browser does: login, confirm a session cookie was *stored* (not just sent — curl won't store a `Secure` cookie from a non-HTTPS response either, matching real browser behavior), then an authenticated follow-up request confirming it succeeds and returns the right account.
## How this was verified
Ran it for real against the live deployment before committing it, both directions:
- Against a throwaway account, over plain HTTP, against a container actually running `VELODROME_ENVIRONMENT=production` → got the expected `FAIL`, with the diagnostic correctly pointing at the Secure-cookie mismatch (this is the literal bug that just happened).
- Same account/URL once the container's environment was `development` (inadvertently, from a manual recreate) → got `PASS`, correctly reflecting that `development` doesn't set `Secure`.
Test accounts created for this were cleaned up afterward (direct SQL delete via the running container — there's no CLI for this yet, matches D18's scope).
## Docs
`deploy/README.md` gets a new section recommending this as the real post-deploy check, replacing "hit /healthz and eyeball it" for anything involving auth — pointed at the real public URL, not an IP, since that's the only way this test means anything.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Found on the actual first deployment: /api/v1/healthz proves the process is
up, but says nothing about whether login actually works, because the
session cookie is set with Secure in production. Test through a plain-HTTP
address (an IP, a bare port, skipping the reverse proxy) and /auth/login
still returns 200 with a valid body — the cookie is just silently dropped by
the client, so the very next request looks unauthenticated. From a browser
this looks exactly like "I logged in and it bounced me straight back to the
login screen," with no error anywhere to point at.
scripts/smoke-test.sh does the real round trip a browser does: login,
confirm a session cookie was actually stored (not just sent), then an
authenticated follow-up request confirming it succeeds and returns the
right account. Verified it actually catches what it's meant to catch before
committing: ran it against a throwaway account over plain HTTP against a
production-mode container and got the expected FAIL with a diagnostic
pointing at the Secure-cookie mismatch, then confirmed PASS once the
container's VELODROME_ENVIRONMENT was (inadvertently, in this case)
development instead.
Documented in deploy/README.md as the real post-deploy check, replacing
"hit /healthz and eyeball it" for anything involving auth.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R2ZKeWkZV7ehf7fivrAkkG
BBergle
merged commit f6005a4fdd into main2026-09-21 22:57:35 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Adds
scripts/smoke-test.sh— found on the actual first deployment that/api/v1/healthzproves nothing about whether login works, because the session cookie isSecurein production and a plain-HTTP test (an IP, a bare port) silently drops it. Login returns 200; the very next request looks unauthenticated; from a browser it looks exactly like "logged in, bounced back to the login screen," with no visible error. That happened for real this session.What it does
Runs the actual round trip a browser does: login, confirm a session cookie was stored (not just sent — curl won't store a
Securecookie from a non-HTTPS response either, matching real browser behavior), then an authenticated follow-up request confirming it succeeds and returns the right account.How this was verified
Ran it for real against the live deployment before committing it, both directions:
VELODROME_ENVIRONMENT=production→ got the expectedFAIL, with the diagnostic correctly pointing at the Secure-cookie mismatch (this is the literal bug that just happened).development(inadvertently, from a manual recreate) → gotPASS, correctly reflecting thatdevelopmentdoesn't setSecure.Test accounts created for this were cleaned up afterward (direct SQL delete via the running container — there's no CLI for this yet, matches D18's scope).
Docs
deploy/README.mdgets a new section recommending this as the real post-deploy check, replacing "hit /healthz and eyeball it" for anything involving auth — pointed at the real public URL, not an IP, since that's the only way this test means anything.🤖 Generated with Claude Code