Hi! Tres Seaver wrote:
yuppie wrote:
yuppie wrote:
In Zope 2.10 'raise_standardErrorMessage', 'zpublisher_exception_hook' and therefore 'Publish.publish' did always (re-)raise errors after rendering. That made sure 'HTTPResponse.exception' was called and CookieCrumbler was able to hook into 'HTTPResponse._unauthorized'.
I'm now trying to figure out how this bug could be fixed: https://bugs.launchpad.net/zope-cmf/+bug/558340
For the record:
Meanwhile I figured out that there is a related launchpad issue https://bugs.launchpad.net/zope2/+bug/372632
Do you have a suggestion for resolving those two bugs?
The original issue reported in https://bugs.launchpad.net/zope2/+bug/372632 seems to be fixed. The issue discussed in comment #15 and later is basically the same as in https://bugs.launchpad.net/zope-cmf/+bug/558340. So there is only *one* issue: If errors are rendered by 'raise_standardErrorMessage' or by an error view they are not re-raised. In that case the error handling in 'publish_module_standard' and 'HTTPResponse.exception' is no longer invoked. I'm not sure how to resolve this. Approach 1: We try to restore the old behavior. The changes were made because the old machinery didn't work with exceptions like zope.publisher.interfaces.NotFound, but I'm optimistic we can find a less intrusive fix for that. Approach 2: The _unauthorized call seems to be the only part of the old error handling that people are actually missing. We could try to add a new hook for that and deprecate big parts of the old code. But is that old code really useless?
and a workaround for the CookieCrumbler issue: http://dev.plone.org/collective/changeset/92340
Hmm, registering an exception view which re-raises the exception is definitely suggestive of something wrong in the plumbing.
Yes. But *if* we don't want restore the old behavior, we could move CookieCrumbler's complete redirect logic into an error view. And get rid of _unauthorized. Cheers, Yuppie