Fix failing Cypress E2E suite: login redirect (cookie_secure) - #3757
Merged
Conversation
Vondry
force-pushed
the
fix/login-redirect-cookie-secure
branch
from
July 23, 2026 13:45
1f46cc3 to
46cb956
Compare
bobvandevijver
requested changes
Aug 3, 2026
Vondry
force-pushed
the
fix/login-redirect-cookie-secure
branch
from
August 3, 2026 13:17
46cb956 to
eefed87
Compare
Setting cookie_secure: true forces the session-domain constraint (used by HttpUtils::createRedirectResponse since the open-redirect fix) to require HTTPS targets. On plain-HTTP installs the saved target path is an http:// URL, so the post-login redirect fails the https-only regexp and falls back to '/', landing users on the homepage instead of /bolt/. This broke every Cypress login test. 'auto' sets the Secure flag only on HTTPS requests (Symfony's recommended default), restoring same-host HTTP redirects while keeping open-redirect protection intact on HTTPS.
Vondry
force-pushed
the
fix/login-redirect-cookie-secure
branch
from
August 3, 2026 15:46
eefed87 to
64df8da
Compare
m_2025-12-01-framework.yaml added `cookie_secure: true` to existing installs, so upgraded sites keep the value that breaks the post-login redirect on plain HTTP. Overwrite it with 'auto' to match the shipped config.
bobvandevijver
changed the title
bobvandevijver
approved these changes
Aug 3, 2026
Member
|
Note that Cypress is still failing, but that seems to be an issue with the API generator and the collection types. But that is something for a different PR -> #3774 |
bobvandevijver
added
🐛 tag: bug
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix login redirect timeouts (
cookie_secure)Problem
Every login-based test failed with:
Authentication succeeded, but users were redirected to the homepage instead of the Bolt dashboard, causing the
/bolt/assertion to time out.Root cause
The regression resulted from the interaction of two independent commits:
fbd0ed3a— Resolve framework configuration deprecationscookie_secure: true(previously omitted, using Symfony's default offalse).db37ed5d— Block open redirect on login endpointnew RedirectResponse(...)withHttpUtils::createRedirectResponse(...)for post-login redirects.HttpUtils::createRedirectResponse()validates redirect targets against a regular expression generated from the session cookie configuration (AddSessionDomainConstraintPass). Withcookie_secure: true, Symfony generates an HTTPS-only pattern ({^https://<host>$}i).The failing flow was:
loginhelper visits/bolt, so Symfony stores the target path ashttp://127.0.0.1:8088/bolt.symfony server:start --no-tls).http://...URL fails the HTTPS-only validation, socreateRedirectResponse()falls back to/./bolt/assertion to time out.This was broader than a test-only issue. Any Bolt installation running over plain HTTP would also have broken login sessions because browsers discard
Securecookies on HTTP.The fix
cookie_secure: 'auto'is Symfony's recommended value for this deprecation. It applies theSecureflag only when the current request uses HTTPS.As a result:
http://andhttps://same-host URLs, restoring the post-login redirect to/bolt/.Security impact: None for correctly configured HTTPS deployments. On HTTPS,
autobehaves identically totrue. On HTTP,truenever provided meaningful protection because browsers discardSecurecookies anyway.