UserHash is always generated for anonymous user

Details

Description

User hash generation process always returns the anonymous user hash. The problem is due to using /_fos_user_context_hash route for hash generation, which is excluded from siteaccess matching, which ultimately means that user will never be authenticated.

This can be circumvented by using the original request URI when generating the hash, since FOS HTTP Cache bundle never did use /_fos_user_context_hash route to match the hash generation request, making it again possible to have a siteaccess match.

Bertrand Dunogier
added a comment - 29/Feb/16 10:45 PM Does it also behave this way when a valid user hash is provided ? I can confirm that with the Sf reverse proxy, content was cached even with a session.
I can indeed confirm this behaviour, but given that the test uses a fake hash...

Edi Modrić
added a comment - 01/Mar/16 2:31 PM I had a similar issue in TagsBundle where repository user was still anonymous in router I implemented, when it should not have been.
I was not able to figure out why, so I just implemented sudo i tag repository
https://github.com/netgen/TagsBundle/commit/945c31f87da59d468584ead3255469f46be8239d

The issue was that sub-requests to /_fos_user_context_hash would match the default siteaccess if using URI part matching. Since no URI part would match, the default siteaccess would be stored in the request, and the master request would not be matched again, leading to unexpected behaviour.

The fix was to exclude the /_fos_user_context_hash route from siteaccess matching, making it the only route for which there is no siteaccess.

Bertrand Dunogier
added a comment - 01/Mar/16 7:25 PM - edited This problem comes from https://jira.ez.no/browse/EZP-23580 .
The issue was that sub-requests to /_fos_user_context_hash would match the default siteaccess if using URI part matching. Since no URI part would match, the default siteaccess would be stored in the request, and the master request would not be matched again, leading to unexpected behaviour.
The fix was to exclude the /_fos_user_context_hash route from siteaccess matching , making it the only route for which there is no siteaccess.
The SecurityListener won't login the user since there is no siteaccess.
This confirms that the user-hash is always the anonymous one. It would need to be tested on other versions, as it sounds possible that stable versions are also affected.

Varnish is configured (3, 4), when requesting the user hash, to copy the Request URI to a x-fos-original-url. This header is then read by the OriginalRequestListener, and used to create the _ez_original_request.

This does not prevent us from documenting that N repositories require N domains: the user hash request will be cached for the first value of the x-fos-original-header, and won't vary on it.

Bertrand Dunogier
added a comment - 04/Mar/16 4:43 PM - edited Might be a false positive, waiting for confirmation on the PR.
Varnish is configured (3, 4), when requesting the user hash, to copy the Request URI to a x-fos-original-url . This header is then read by the OriginalRequestListener, and used to create the _ez_original_request .
This does not prevent us from documenting that N repositories require N domains: the user hash request will be cached for the first value of the x-fos-original-header , and won't vary on it.