Fix failing Cypress E2E suite: login redirect (cookie_secure) and CI PHP 8.4 bump

[Vondry]

Summary

This MR fixes two independent issues that caused the Cypress end-to-end suite to fail in CI. The changes are unrelated and can be reviewed independently:

1. Login redirect timeouts — a cookie misconfiguration redirected users to / instead of /bolt/ after login.
2. 502 Bad Gateway errors — the e2e job ran on a PHP version that the freshly resolved dependency set no longer supports.

Two files change:

• config/packages/framework.yaml — cookie_secure: true → cookie_secure: 'auto'
• .github/workflows/cypress_tests.yaml — PHP_VERSION: 8.2 → PHP_VERSION: 8.4

---

Part 1 — Fix login redirect timeouts (cookie_secure)

Problem

Every login-based test failed with:

expected http://127.0.0.1:8088/bolt/ but got http://127.0.0.1:8088/

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:

Commit	Change
fbd0ed3a — Resolve framework configuration deprecations	Set cookie_secure: true (previously omitted, using Symfony's default of false).
db37ed5d — Block open redirect on login endpoint	Replaced new RedirectResponse(...) with HttpUtils::createRedirectResponse(...) for post-login redirects.

HttpUtils::createRedirectResponse() validates redirect targets against a regular expression generated from the session cookie configuration (AddSessionDomainConstraintPass). With cookie_secure: true, Symfony generates an HTTPS-only pattern ({^https://<host>$}i).

The failing flow was:

1. The Cypress login helper visits /bolt, so Symfony stores the target path as http://127.0.0.1:8088/bolt.
2. CI runs the application over plain HTTP (symfony server:start --no-tls).
3. After authentication, the saved http://... URL fails the HTTPS-only validation, so createRedirectResponse() falls back to /.
4. Authentication succeeds, but the user lands on the homepage, causing the /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 Secure cookies on HTTP.

The fix

cookie_secure: 'auto' is Symfony's recommended value for this deprecation. It applies the Secure flag only when the current request uses HTTPS.

As a result:

• On HTTP requests, redirect validation accepts both http:// and https:// same-host URLs, restoring the post-login redirect to /bolt/.
• On HTTPS requests, validation remains HTTPS-only, preserving protection against open redirects and scheme downgrades.

Security impact: None for correctly configured HTTPS deployments. On HTTPS, auto behaves identically to true. On HTTP, true never provided meaningful protection because browsers discard Secure cookies anyway.

---

Part 2 — Fix 502 Bad Gateway errors (PHP 8.4)

Problem

With Part 1 fixed, the login tests passed, but the content- and API-related tests then failed with:

502: Bad Gateway

on serializer-backed routes, including the /api/... content endpoints, public content-rendering routes (/entry/..., /page/..., /test/...), and content listings. Admin pages that do not hit the serializer continued working, making the failures appear unrelated.

Root cause

composer.lock is intentionally gitignored, so CI resolves dependencies from scratch on every run based on composer.json ("php": ">=8.2").

The e2e workflow was pinned to PHP 8.2. Under PHP 8.2, the freshly resolved API Platform / Symfony serializer stack fatals while serializing or instantiating content entities, causing every serializer-backed route to return HTTP 502. Non-serializer admin pages were unaffected.

The fix

Upgrade the Cypress workflow to PHP 8.4, allowing Composer to resolve a dependency set that works correctly at runtime. All serializer-backed routes then render successfully.

Note for reviewers: composer.json still declares "php": ">=8.2", but the currently resolved dependency graph no longer runs correctly on PHP 8.2. If PHP 8.2 remains a supported target, that compatibility mismatch should be addressed separately (for example, by constraining the affected packages or raising the declared minimum PHP version). This MR only aligns the CI runtime with the dependency set that currently works.