Tell the client how long the Mercure authorization cookie lives

[fashxp]

Part of the fix for pimcore/platform-version#346.

Problem

The Mercure hub authorises a subscription exactly once, when the EventSource connects, from the
mercureAuthorization cookie sent with that request. The cookie lives cookie_lifetime seconds
(3600 by default) while a Studio tab lives for as long as the user leaves it open, and the hub
closes every stream on its own write_timeout (600s by default) so the browser reconnects roughly
every nine minutes. Any reconnect made after the cookie expired is accepted as an anonymous
subscription by a hub that allows those, and then receives no private update ever again: no error,
no onerror, and the client keeps reporting a healthy stream.

The client has to renew the cookie before it expires, and today it has no way to know when that is.

Change

POST /mercure/auth now returns the configured lifetime next to the cookie it sets:

{ "cookieLifetime": 3600 }

• new Mercure\Schema\Authorization response DTO (OpenAPI documented as MercureAuthorization)
• HubServiceInterface::getCookieLifetime() exposes the configured
  pimcore_studio_backend.mercure_settings.cookie_lifetime
• JwtController::auth() returns that DTO as the response body

Returning the lifetime rather than an absolute expiry keeps it immune to clock differences
between server and browser: the value is relative to the response the client just received.

Backward compatibility

Additive only. The action's return type stays Response (JsonResponse is one), the status code
and the Set-Cookie header are unchanged, and a client that ignores the body behaves exactly as
before. HubServiceInterface is @internal.

The consuming side is pimcore/studio-ui-bundle#4009, which reads the field defensively and falls
back to a one hour assumption, so the two can be merged in either order.

Verification

• new HubServiceTest (3 cases), including a regression test that the advertised lifetime and the
  actual cookie expiry are derived from the same value: if they drift, a client that renews "in
  time" still reconnects with a dead cookie, which is precisely the failure this is meant to end
• vendor/bin/codecept run Unit tests/Unit/Mercure green (15 tests)
• PHPStan level 6 clean on src/Mercure
• php-cs-fixer clean on the touched files
• serialisation of the new DTO checked to produce {"cookieLifetime":3600}

[Copilot]

Pull request overview

Exposes the Mercure authorization cookie lifetime so clients can renew before expiry.

Changes:

• Adds an authorization response DTO and OpenAPI schema.
• Returns the configured cookie lifetime from /mercure/auth.
• Adds HubService lifetime and expiry tests.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/Mercure/Controller/JwtController.php	Returns lifetime JSON with the cookie.
src/Mercure/Schema/Authorization.php	Defines the response DTO.
src/Mercure/Service/HubService.php	Exposes the configured lifetime.
src/Mercure/Service/HubServiceInterface.php	Adds the lifetime contract.
tests/Unit/Mercure/Service/HubServiceTest.php	Tests lifetime and cookie expiry.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud