Details
-
Story
-
Resolution: Fixed
-
High
-
5.0.0-dev
-
Aconcagua Sprint 1, Aconcagua Sprint 2
-
3
Description
At the moment, HttpCache is completely public and only vary on the ETag, not on a user based information.
To make the cache vary on the user hash (like it was the case in legacy), we need to rely on a custom Http request header (e.g. X-User-Hash).
$response = new Response(); $response->setVary( 'X-User-Hash' );
To make this possible, we need to calculate and store this user hash somehow at login time, in a cookie for instance. Thus, the reverse proxy (Symfony one or Varnish) can extract it and set the custom request header in a very easy way.
Solution
- In user/login legacy module, compute the user hash when the user is logged in.
- Trigger an user/login ezpEvent (filter type to be able to pass the computed user hash)
- From Symfony, attach a listener to this event and make it set the cookie
- In Symfony reverse proxy (HttpCache), catch the cookie if present and set the value in X-User-Hash request header before the lookup action.
Attachments
Issue Links
- discovered while testing
-
EZP-21281 Warning: Could not generate user hash ! Fallback to anonymous hash
- Closed
- relates to
-
EZP-19959 Cache not working correctly with eZ Demo on eZ Publish 5
- Closed
-
EZP-20215 Scalability issue in the way HTTP cache is stored
- Closed
-
EZP-20880 HttpCache purge is not being triggered when permissions change
- Closed
-
EZP-21170 Implement a maintenance/cleanup command
- Closed
-
EZP-21180 Write documentation on context aware HTTP caching
- Closed
-
EZP-20438 Make it possible to use a custom controller to handle a content/location
- Closed
- links to