Details
-
Bug
-
Resolution: Fixed
-
High
-
5.4.0-beta1
-
None
Description
Summary:
If using urielement matcher the site is matched against '/_fos_user_context_hash' while generating the X-User-Hash causing default site access to be used during both getting the user hash and the original request.
Long description
After logging in a redirect occurs and the following happens:
1. The page is loaded from the cache via \FOS\HttpCacheBundle\HttpCache::handle
2. The user hash header is not present yet so \FOS\HttpCacheBundle\HttpCache::handle::getUserHash is called to get it
3. A forward request is made doing and a siteaccess match is performed during the process and stored in the router. If you are using an urlelement matcher, it is matched against '/_fos_user_context_hash'. Since this is not a valid siteaccess the default site access is used.
4. The user hash is returned and the user hash header is updated
5. The original request is now handled and since a site access match was made during step 3, the default siteaccess is used instead of the expected urielement matcher
Attachments
Issue Links
- discovered while testing
-
EZP-22400 Use FOSHttpCacheBundle + Symfony Cache + Varnish 4 support
- Closed
- is duplicated by
-
EZP-23574 Module not found logging in and out from ezdemo_site_admin
- Closed
- relates to
-
EZP-25505 UserHash is always generated for anonymous user
- Backlog
-
EZP-23632 Exception when running eZ Publish behind built in reverse proxy
- Closed
-
EZP-23930 Adapt HttpCache to comply FOSHttpCacheBundle 1.2
- Closed
- links to