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).
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests