[Zope-CMF] [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager

Dieter Maurer dieter at handshake.de
Sun Dec 17 12:52:17 EST 2006


Crosspost: 'Reply-To' set to 'zope-cmf'.

We nearly escaped a catastrophy: a page with sensitive personal
information ended in a shared cache and was delivered to arbitrary
people. This happened despite the fact that the template generating
the page contained a "response.setHeader('Cache-Control', 'no-cache')"
(and related headers for non HTTP/1.1 clients).

The analysis quickly revealed broken design in the
CMF Caching Policy Manager (CPM)
as the cause:

  *  it has applied its general policy depite the fact that
     the template itself has provided more adequate decisions with
     respect to caching

  *  the caching policy manager action affects the complete response.
     Therefore, only the top level object, the object that controls
     the response content, should influence the CPM decisions.

     In the concrete case, the primary template did not trigger
     the CPM but the call of a secondary template responsible only for a tiny
     part of the response.

The same problem also affects Zope's HTMLCacheManager.


The description indicates in what direction the CPM should get fixed:

  * If the response already provides cache control, the CPM should
    not override it, as it is likely that the specific information
    available to the response generating process is more trustworthy
    then the general CPM policies.

    This is arguable, especially as it changes the current behaviour.
    Maybe, it should be controlled by an additional configuration option.

  * The CPM (and Zope's HTTP Cache Manager) must set cache headers
    only based on the object that generated the (complete) response
    entity and not based on other objects called during the request
    (and probably only responsible for part of the entity).


-- 
Dieter


More information about the Zope-CMF mailing list