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

          Edi Modrić created issue -
          Bertrand Dunogier made changes -
          Field Original Value New Value
          Status Open [ 1 ] Confirmed [ 10037 ]
          Bertrand Dunogier made changes -
          Link This issue relates to EZP-23580 [ EZP-23580 ]
          Bertrand Dunogier made changes -
          Labels cache http
          Bertrand Dunogier made changes -
          Affects Version/s 2016.02 [ 14501 ]
          Bertrand Dunogier made changes -
          Summary No Vary: X-User-Hash with FOS HTTP Cache bundle 1.3.7 UserHash is always generated for anonymous user
          André Rømcke made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16255 ]
          André Rømcke made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16257 ]
          Edi Modrić made changes -
          Description After upgrading FOS HTTP Cache bundle from version 1.3.6 to 1.3.7, Vary header is missing "X-User-Hash" value when request contains the X-User-Hash header.

          Curl call that verifies the problem:

          With FOS HTTP Cache Bundle 1.3.6 (notice the presence of "X-User-Hash" in Vary header):

          {code}
          eddie@abyss [~/www/netgensite] ( ± master ● ● ) $ curl -v -H 'X-User-Hash: 123' http://netgensite.local -o /dev/null
          * Rebuilt URL to: http://netgensite.local/
            % Total % Received % Xferd Average Speed Time Time Time Current
                                           Dload Upload Total Spent Left Speed
            0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 127.0.0.1...
          * Connected to netgensite.local (127.0.0.1) port 80 (#0)
          > GET / HTTP/1.1
          > Host: netgensite.local
          > User-Agent: curl/7.43.0
          > Accept: */*
          > X-User-Hash: 123
          >
          < HTTP/1.1 200 OK
          < Date: Fri, 26 Feb 2016 13:09:24 GMT
          < Server: Apache/2.4.18 (Ubuntu)
          < Cache-Control: public, s-maxage=300
          < X-Cache-Debug: 1
          < Vary: X-User-Hash,Accept-Encoding
          < X-Location-Id: 2
          < X-Debug-Token: e0ece9
          < X-Debug-Token-Link: /_profiler/e0ece9
          < Transfer-Encoding: chunked
          < Content-Type: text/html; charset=UTF-8
          <
          { [16058 bytes data]
          100 48793 0 48793 0 0 61178 0 --:--:-- --:--:-- --:--:-- 61144
          * Connection #0 to host netgensite.local left intact
          {code}

          With FOS HTTP Cache Bundle 1.3.7 (notice the absence of "X-User-Hash" in Vary header):

          {code}
          eddie@abyss [~/www/netgensite] ( ± master ● ● ) $ curl -v -H 'X-User-Hash: 123' http://netgensite.local -o /dev/null
          * Rebuilt URL to: http://netgensite.local/
            % Total % Received % Xferd Average Speed Time Time Time Current
                                           Dload Upload Total Spent Left Speed
            0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 127.0.0.1...
          * Connected to netgensite.local (127.0.0.1) port 80 (#0)
          > GET / HTTP/1.1
          > Host: netgensite.local
          > User-Agent: curl/7.43.0
          > Accept: */*
          > X-User-Hash: 123
          >
            0 0 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0< HTTP/1.1 200 OK
          < Date: Fri, 26 Feb 2016 13:11:14 GMT
          < Server: Apache/2.4.18 (Ubuntu)
          < Cache-Control: max-age=1, no-cache, public, s-maxage=300
          < X-Cache-Debug: 1
          < X-Location-Id: 2
          < X-Debug-Token: 6951ee
          < X-Debug-Token-Link: /_profiler/6951ee
          < Vary: Accept-Encoding
          < Transfer-Encoding: chunked
          < Content-Type: text/html; charset=UTF-8
          <
          { [16049 bytes data]
          100 48793 0 48793 0 0 10669 0 --:--:-- 0:00:04 --:--:-- 14487
          * Connection #0 to host netgensite.local left intact
          {code}
          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 made changes -
          Link This issue relates to EZP-25533 [ EZP-25533 ]
          Edi Modrić made changes -
          Affects Version/s 2014.11 [ 13681 ]
          Edi Modrić made changes -
          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.
          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 for some reason.
          Edi Modrić made changes -
          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 for some reason.
          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.
          Bertrand Dunogier made changes -
          Status Confirmed [ 10037 ] Backlog [ 10000 ]
          Bertrand Dunogier made changes -
          Status Backlog [ 10000 ] Development [ 3 ]
          Assignee Bertrand Dunogier [ bertrand.dunogier@ez.no ]
          Bertrand Dunogier made changes -
          Status Development [ 3 ] Development Review [ 10006 ]
          Bertrand Dunogier made changes -
          Status Development Review [ 10006 ] InputQ [ 10001 ]
          Assignee Bertrand Dunogier [ bertrand.dunogier@ez.no ]
          Bertrand Dunogier made changes -
          Remote Link This issue links to "PR ezsystems/ezpublish-kernel#1602 (Web Link)" [ 16265 ]
          Bertrand Dunogier made changes -
          Status InputQ [ 10001 ] Development [ 3 ]
          Assignee Bertrand Dunogier [ bertrand.dunogier@ez.no ]
          Bertrand Dunogier made changes -
          Status Development [ 3 ] Development Review [ 10006 ]
          Bertrand Dunogier made changes -
          Status Development Review [ 10006 ] Backlog [ 10000 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ] This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ] This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Sarah Haïm-Lubczanski (Inactive) made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Sarah Haïm-Lubczanski (Inactive) made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ] This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ] This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16412 ] This issue links to "Page (eZ Documentation)" [ 16412 ]
          Dominika Kurek made changes -
          Remote Link This issue links to "Page (eZ Documentation)" [ 16408 ] This issue links to "Page (eZ Documentation)" [ 16408 ]
          Alex Schuster made changes -
          Workflow EZ* Development Workflow [ 97885 ] EZEE Development Workflow [ 108082 ]
          Bertrand Dunogier made changes -
          Assignee Bertrand Dunogier [ bertrand.dunogier@ez.no ]

            People

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

              Dates

              • Created:
                Updated: