Details

    • Type: Epic Epic
    • Status: Open
    • Priority: High High
    • Resolution: Unresolved
    • Affects Version/s: 1.9.1
    • Fix Version/s: Customer request
    • Component/s: Caching
    • Labels:
      None
    • Epic Name:
      Sensitive content

      Description

      According to reported customer issue, to be able to comply with upcoming changes to BDSG (german Federal data protection act) we need to be able to tell http response cache to not be marked as public and somehow just cache it in HTTP Cache but not other places after that (Browsers, ISP proxies, ..)

      As in:
      1. eZ Platform depends on being able to use HTTP Cache (Varnish,..)

      • it's its native view cache system with close integration to purge whenever content expires

      2. Currently only way to cache content is to mark it as public

      • Making it is cached in HTTP Cache (Varnish,..) and also in Browsers and ISP proxies

      The last bit is what might violate the upcoming privacy rules, as it effectively means for the length of the configured global ttl (cache Time To Live), all cached content, including those that might be sensitive (including example from original report: Users with email and user names in REST response) will be cached across Varnish, ISP Proxy and Browsers. If the ttl is set to a high number which is what we will start recommending soon (ezplatform-http-cache multi tagging is aiming for this), then the issue is made worse.

      Some possible ways this could be solved:

      • Content model support for marking content types as being sensitive, and use that during building the response so that Varnish will adjust http headers
      • Change our VCL to always mark responses that vary on user hash as private, missing out on browser cache when that might be ok to cache
      • Introduce some setting for toggling the previous option

        Issue Links

          Issues in Epic

            Activity

            Hide
            Bertrand Dunogier added a comment - - edited

            Due to EZP-27621, I have investigated the internals of fos-http-cache-bundle. It would appear that it may be flexible enough, and we may be able to use it to match content requests.

            I'd lean towards keep the configuration in content view rules. It is a mandatory part of the path the developers follow, and we already have a matching going on there (note to Adam: it does not prevent us from implementing an expression language based Matcher for Content View ). It could be like this:

            content_view:
              full:
                sensitive_content:
                  match:
                    Identifier\ContentType: "whatever"
                  cache_control: sensitive
            

            (sensitive would be configured somewhere, like named cache control settings)

            We should be able to mimic what fos-http-cache-bundle does with the configuration, and create our own FosHttpCache matching rules that operate on content. I had a look at them, and we could use our own Response and Request matchers.

            What do you think ?

            By the way, would by the way a max-age of 0 and a s-max-age > 0 fix the sensitivity / caching problem ?

            Show
            Bertrand Dunogier added a comment - - edited Due to EZP-27621 , I have investigated the internals of fos-http-cache-bundle. It would appear that it may be flexible enough, and we may be able to use it to match content requests. I'd lean towards keep the configuration in content view rules. It is a mandatory part of the path the developers follow, and we already have a matching going on there (note to Adam: it does not prevent us from implementing an expression language based Matcher for Content View ). It could be like this: content_view: full: sensitive_content: match: Identifier\ContentType: "whatever" cache_control: sensitive ( sensitive would be configured somewhere, like named cache control settings) We should be able to mimic what fos-http-cache-bundle does with the configuration, and create our own FosHttpCache matching rules that operate on content. I had a look at them, and we could use our own Response and Request matchers. What do you think ? By the way, would by the way a max-age of 0 and a s-max-age > 0 fix the sensitivity / caching problem ?
            Hide
            André Rømcke added a comment - - edited

            I think we might be onto something , setting max-age to 0 and s-max-age > 0 and getting Varnsh VCL + Symonfy proxy to unset this by default to avoid other proxies caching it is a good direction here which will solve it without end user having to do anything. dbu mentioned the same as alternative to FOSHttpCache's reverse_proxy_ttl setting which requires inline C in VCL (a no go for most of our users).

            If we can aim to end up with the following over time then we would have a fast and sensible default which does not need a specific sensitive content feature:
            client < validation (etag/modified since) > trusted reverse proxy < expiration (long ttl + purge) > eZ

            validation against proxy will be fast, so does not involve the same downsides as invalidation against backend: having to generate everything to know if it changed. Proxy kind of "knows this already", since page is still considered fresh until it's purged / expired.

            Show
            André Rømcke added a comment - - edited I think we might be onto something , setting max-age to 0 and s-max-age > 0 and getting Varnsh VCL + Symonfy proxy to unset this by default to avoid other proxies caching it is a good direction here which will solve it without end user having to do anything. dbu mentioned the same as alternative to FOSHttpCache's reverse_proxy_ttl setting which requires inline C in VCL (a no go for most of our users) . If we can aim to end up with the following over time then we would have a fast and sensible default which does not need a specific sensitive content feature: client < validation (etag/modified since) > trusted reverse proxy < expiration (long ttl + purge) > eZ validation against proxy will be fast, so does not involve the same downsides as invalidation against backend: having to generate everything to know if it changed. Proxy kind of "knows this already", since page is still considered fresh until it's purged / expired.
            Hide
            André Rømcke added a comment -

            POC for Varnish: https://github.com/ezsystems/ezplatform/pull/216#issuecomment-336929073 Changes default VCL to mark responses varying on User-hash to not be cached by shared proxies and browsers, to solve this issue without the need for a new feature around it.

            Would need similar logic also for Symfony Proxy if we go in that direction.

            Show
            André Rømcke added a comment - POC for Varnish: https://github.com/ezsystems/ezplatform/pull/216#issuecomment-336929073 Changes default VCL to mark responses varying on User-hash to not be cached by shared proxies and browsers, to solve this issue without the need for a new feature around it. Would need similar logic also for Symfony Proxy if we go in that direction.

              People

              • Assignee:
                Unassigned
                Reporter:
                André Rømcke
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: