Global navigation

   Documentation Center
   eZ Studio & eZ Platform
     User Manual
     Technical Manual
   eZ Publish 4.x / legacy

eZ Publish (5.x)

eZ Publish 5.x | For eZ Platform & eZ Studio topics see Technical manual and User manual, for eZ Publish 4.x and Legacy topics see eZ Publish legacy

Skip to end of metadata
Go to start of metadata

This feature is available from eZ Publish 5.2 / 2013.07


  1. Reverse proxy receives the HTTP request (without the user hash).
  2. Reverse proxy does a sub-request (emulated in the case of HttpCache).

    Sub-request must have the following headers:

    • Accept: application/vnd.ez.UserHash+text
    • Original cookie (mainly to keep trace of the sessionId)
  3. eZ Publish returns an HTTP response containing the user hash in X-User-Hash header.

  4. Reverse proxy adds the X-User-Hash header to the original request.

Note on performance

User hash is not generated for each AUTHENTICATE request. It is cached using the Cookie header string as key.
Hence each user has its own hash, generated once per session.

Hash generation being based by default on roles and limitations, a user can share the same hash with another one if their profile are similar. This is precisely what offers the possibility to share HTTP cache between several logged-in users.


You can customize user hash generation. Read How to customize UserHash generation in the developer cookbook to learn more about this.


Described behavior comes out of the box with Symfony reverse proxy, but it's of course possible ot use Varnish to achieve the same.

This can be done thanks to Varnish Curl vmod.

Securing hash generation request

By default, hash generation requests are granted for localhost (

If you want to enlarge the scope (e.g. if your Varnish server is not running on the same machine), you can override canGenerateUserHash() protected method in your main kernel class (mostly EzPublishKernel).

  • No labels