I have a default setup where front is accessible on http://localhost:8081 and admin on http://localhost:8081/admin
Varnish is enabled !

In default configuration, logging into admin will create a session cookie named eZSESSID21232f297a57a5a743894a0e4a801fc3, loggin into front-end (siteaccess=site) will create a session cookie named eZSESSID98defd6ee70dfb1dea416cecdf391f58

Test scenario #1 where caching will work:

1. Make sure you don't have /admin opened in any tab ( admin-ui might sendt XHR request which may create inconsitent test results, depending on timing of those XHR requests)
2. clear HTTP cache : ./bin/console fos:httpcache:invalidate:tag ez-all -v
3. load "http://localhost:8081/" in your browser
4. load "http://localhost:8081/" again, you'l notice it is cached

Test scenario #2 where caching will not work:

1. load "http://localhost:8081/" in your browser
2. create a new tab and login to http://localhost:8081/admin
3. clear HTTP cache : ./bin/console fos:httpcache:invalidate:tag ez-all -v
4. First refresh admin page : "http://localhost:8081/"
5. Visit frontpage : load "http://localhost:8081/" in your browser
6. load "http://localhost:8081/" again, you'l notice it is NOT cached ( by for instance monitoring webserver's access log, or look at the response header "AGE" )

The problem starts in step 4: here, varnish will fetch the user-context-hash for user with session hash eZSESSID21232f297a57a5a743894a0e4a801fc3.
Request will be

-   ReqHeader      cookie: eZSESSID21232f297a57a5a743894a0e4a801fc3=qri5d6k4h52t0b8e2uh8pe4gl2;
-   ReqURL         /_fos_user_context_hash
-   ReqHeader      accept: application/vnd.fos.user-context-hash
-   ReqHeader      x-fos-original-url: /admin
-   ReqURL         /_fos_user_context_hash

The response for /_fos_user_context_hash is:

-   RespHeader     Content-Type: application/vnd.fos.user-context-hash
-   RespHeader     X-User-Context-Hash: 6d9cae3c3acb6847e2a3d1d572fe062aaaf7d65cb64531662334c916f8424f9f
-   RespHeader     Cache-Control: max-age=600, public
-   RespHeader     Date: Tue, 23 Aug 2022 13:37:04 GMT
-   RespHeader     Vary: Origin, cookie, authorization
-   RespHeader     X-Cache-Debug: 1
-   RespHeader     xkey: ez-user-context-hash ez-all fos_http_cache_hashlookup-qri5d6k4h52t0b8e2uh8pe4gl2
-   RespHeader     X-Powered-By: Ibexa Experience v3
-   RespHeader     X-Debug-Token: a2a495
-   RespHeader     X-Debug-Token-Link: http://localhost:8081/_profiler/a2a495
-   RespHeader     X-Robots-Tag: noindex
-   RespHeader     X-Varnish: 295262 557525
-   RespHeader     Age: 35
-   RespHeader     Via: 1.1 varnish (Varnish/7.1)
-   RespHeader     Accept-Ranges: bytes

Note the Vary header, it does not vary on x-fos-original-url.

Then, in step 5 the request for user-context-hash will be the same except for x-fos-original-url:

-   ReqHeader      x-fos-original-url: /

However, response will not vary on x-fos-original-url, so varnish will fetch the response from cache.. So now it get's the user-context-hash which has admin siteaccess context.

It will then use that user-context hash to fetch /. / is not in the cache and will be fetched from origin. Because the user-context-hash has wrong context, Ibexa DXP will return will header

Cache-Control: max-age=0, must-revalidate, no-cache, no-store, private, s-maxage=86400

And this will not be cached by varnish

Some suggestions for what do do about this:

• Make /_fos_user_context_hash vary on x-fos-original-url. This will basically destroy the hit-ratio for /_fos_user_context_hash and cause a lot more of these requests to hit origin
• Make /_fos_user_context_hash vary on x-fos-original-url, but only if is siteaccecss matching is somewhat based on uri
• Stop having separate cookie names for the session per siteaccess
• But I believe that one of the main reason for this session cookie name functionallity was made specifically to prevent admin users to be automatically logged into front-end when uri matching is enabled
• However, my testcase here shows that this use-case is anyway broken
• Document that obsticales mentioneds here

Note : While testing this I also had some edge-case where origin would issue this header when fetching the user-context-hash:

Set-Cookie: eZSESSID21232f297a57a5a743894a0e4a801fc3=qri5d6k4h52t0b8e2uh8pe4gl2; expires=Thu, 01-Jan-1970 00:01:00 GMT; Max-Age=0; path=/; httponly; samesite=none

(unsure if the samesite value was none though..
This header was set by this line in public/index.php

$response = $kernel->handle($request);

However, the response did not exist in the $response object, so the header was set directly in the output buffer it seems. However, I wasn't able to reproduce it for a very long time and was unable to determine where that came from.