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:
>> For the record:
>> Meanwhile I figured out that there is a related launchpad issue
> 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
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:
> 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
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -