Steps to reproduce
- Set-up eZ Platform behind Varnish (use standard VCL: https://github.com/ezsystems/ezplatform-http-cache/blob/master/docs/varnish/vcl/varnish5.vcl).
- Configure different session cookie names for admin and frontend SA.
- Add the new controller, service, view and views configuration as explained below.
- Create an editor's account, for instance, John Doe.
- Create a new section, for instance, Restricted.
- Deny access for the anonymous group to the contents of Restricted section.
- Create a random folder in Standard section. Let's assume that it has LocationId: 100.
- Create a new random content object. Assign it to the Restricted section. Let's assume that it has ContentId: 102.
- Clear all browser cookies.
- Try to open the content created in step 7 using frontend SA as anonymous. You should not be able to see the content loaded via ESI.
- Login into the frontend SA as John Doe.
- Reload the page with restricted content. It should be visible now.
- Login into the backend SA as admin.
- Do some random clicks in AdminUI (go for Content, Media, whatever).
- Logout from the backend SA.
- Try to open the restricted page on the frontend. You shouldn't be able to view the content.
You should be able to see restricted content due to the fact that your frontend SA session is still active.
Technical reason for the issue
- When you open the page, as described in step 10, then the ESI call gets cached and vary on anonymous X-User-Hash. /_fos_user_context_hash call return anonymous hash, gets cached and vary on Cookie/Authorization (in this step there is no cookies).
- When you open the page, as described in step 12, the ESI call gets cached and vary on X-User-Hash (editor’s one). /_fos_user_context_hash call returns X-User-Hash for editor, gets cached and vary on Cookie/Authorization (there is a cookie for frontend SiteAccess session).
- When you login to the backend SA, as described in steps 13 & 14 then /_fos_user_context_hash call returns X-User-Hash for admin, gets cached and vary on Cookie/Authorization (there are two cookies now, one for the frontend SA and one for the backend SA)
- When you logout from the backend SA, as described in step 15, then there is a redirection to /admin/login, so a new “empty” session is created and the new backend SA cookie is set. Redirect causes next call for X-User-Hash. It returns anonymous hash (due to the “empty” backend cookie) and gets cached, vary on Cookie/Authorization. Therefore the anonymous X-User-Hash gets cached and vary on these two cookies:
- “empty” backend SA session cookie
- valid frontend SA session cookie
Due to the last point, a response for the next ESI call for the frontend restricted page is considered as already existing in the cache since the request uses anonymous hash. There is no call for the X-User-Hash since there is already cached one for the mentioned set of cookies.
- Do not set the new, "empty" cookie after logout.
- Disable caching for X-User-Hash.
- Add some unique vary for X-User-Hash calls besides Cookie.
Controller, view, views configuration for step 2: