Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-25505

UserHash is always generated for anonymous user

    Details

    • Type: Bug Bug
    • Status: Backlog
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: 2014.11, 2015.12.1, 16.02
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      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.

      EDIT: This also happens on 2014.11, but over there, the above doesn't help because this commit never ended up in 2014.11: https://github.com/ezsystems/ezpublish-kernel/commit/b4b02419847c991d24c5938962d83cda90aaca65 and role ID context hash provider uses the second "inherit" param.

        Issue Links

          Activity

          Hide
          Edi Modrić added a comment -

          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

          Show
          Edi Modrić added a comment - 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
          Hide
          Bertrand Dunogier added a comment - - 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.

          Show
          Bertrand Dunogier added a comment - - 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.
          Hide
          Bertrand Dunogier added a comment -

          Note: this also means that marking http-cache-bundle 1.3.7 as conflicting won't fix anything.

          Show
          Bertrand Dunogier added a comment - Note: this also means that marking http-cache-bundle 1.3.7 as conflicting won't fix anything.
          Show
          Bertrand Dunogier added a comment - PR https://github.com/ezsystems/ezpublish-kernel/pull/1602
          Hide
          Bertrand Dunogier added a comment - - 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.

          Show
          Bertrand Dunogier added a comment - - 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.

            People

            • Assignee:
              Unassigned
              Reporter:
              Edi Modrić
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: