Skip to content

fix: stop Secure session cookies from breaking login on plain-HTTP deployments - #214

Merged
morcen merged 1 commit into
mainfrom
fix/issue-120-session-secure-cookie-tls-mismatch
Sep 4, 2026
Merged

fix: stop Secure session cookies from breaking login on plain-HTTP deployments#214
morcen merged 1 commit into
mainfrom
fix/issue-120-session-secure-cookie-tls-mismatch

Conversation

@morcen

@morcen morcen commented Sep 3, 2026

Copy link
Copy Markdown
Owner

What was broken

config/session.php defaulted the secure session-cookie flag to true whenever APP_ENV=production, regardless of whether the app was actually reachable over HTTPS. The repo's own shipped "production" paths never terminate TLS:

  • docker-compose.yml's app/queue/scheduler services set APP_ENV=production, but the nginx service only listens on port 80 — no TLS anywhere in the stack.
  • DEPLOYMENT.md's quick-start docker run --target production -p 80:9000 -e APP_ENV=production ... example exposes the app directly over plain HTTP.

Browsers silently discard Secure-flagged cookies sent over plain HTTP. So anyone following either of those documented paths would get a session cookie that never survives a request — login just appeared to do nothing, with no error surfaced anywhere. This was a functional regression introduced when secure was given a production-based default (previously it had no default at all, so this exact path worked).

What changed

  • config/session.php: secure now defaults based on whether APP_URL is served over https://, instead of on APP_ENV. This reflects the actual public-facing transport rather than the deployment environment's name, so it self-corrects for every current and future deployment recipe without needing per-example patches. SESSION_SECURE_COOKIE still works as an explicit override in either direction.
  • DEPLOYMENT.md: added a short note next to the affected quick-start example explaining the new default and telling operators to set APP_URL=https://your-domain.com once TLS is actually terminated in front of the app.
  • tests/Unit/SessionSecureCookieConfigTest.php: updated/extended to cover the new APP_URL-based default, including a direct regression test for the APP_ENV=production + plain-HTTP APP_URL combination described above, a behind-TLS production case, and the explicit-override case.

Verification

  • vendor/bin/pint --dirty — clean, no changes needed.
  • composer test (full suite) — 208 passed, 7 skipped (pre-existing, unrelated skips), 0 failed.

Fixes #120

…ployments

config/session.php previously defaulted the 'secure' session cookie flag
to true whenever APP_ENV=production, regardless of whether the app was
actually served over HTTPS. The shipped docker-compose.yml stack and the
quick-start docker run example in DEPLOYMENT.md both set
APP_ENV=production but never terminate TLS, so browsers silently
dropped the Secure-flagged session cookie and login appeared to just
do nothing, with no error surfaced anywhere.

Default 'secure' based on whether APP_URL is served over https://
instead, since that reflects the actual public-facing transport rather
than the deployment environment name. SESSION_SECURE_COOKIE remains an
explicit override for anyone who needs to force the behavior either
way.

Also documents the new default near the affected DEPLOYMENT.md example
so operators know to set APP_URL=https://... once TLS is terminated in
front of the app.

Fixes #120
@morcen
morcen merged commit 157e4d6 into main Sep 4, 2026
2 checks 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.

Session cookies now default to Secure in production, but the shipped Docker/deployment path never terminates TLS — login silently breaks

1 participant