[Grok-dev] Final touches for a 1.0 "proper"
janwijbrand at gmail.com
Thu Oct 1 14:05:18 EDT 2009
Martijn Faassen wrote:
>>> I took a look at it. How is exempt-exceptions configured?
>> Like I In the debug.ini file for your grokproject, something like:
>> use = egg:Debugging#debug
>> filter-with = translogger
>> exempt-exceptions = zope.security.interfaces.IUnauthorized,
>> Ofcourse, grokproject will generate one for you with the IUnauthorized
>> exempt already in there.
> I took a bit more context to figure out what this was about again. I
> think a recap of the original problem and a few hints about the shape of
> the solution would have helped put the whole problem into my mind again.
Ah, ok, sorry for not providing enough context.
>>> I think this needs some documentation on when and how one would use it.
>> Sure, but I wanted some feedback on the approach first.
>> Do I understand that people generally agree on this approach? Surely we
>> need to document the behaviour, for example in the upgrade notes.
> So here is my thinking process to try to figure out what this was about
> The original problem was that Unauthorized was not handled in zope
> proper if the zope publisher was configured not to handle any exceptions
> itself. This is bad in debug mode with WSGI. We added a modification so
> we can configure the zope publisher not to reraise some exceptions like
> Unauthorized if things are configured that way.
I'd rephrase that like so: The original problem was that when running
zope in debug mode with the WSGI evalexception middleware, zope is
instructed not to handle execeptions itself at all, including the
This is bad, as the normal authentication mechanisms of zope then are
not triggered and as a result you cannot login.
We added a modification so that although zope was instructed not to
handle errors, to make an exception (no pun intended) for Unauthorized
to have this handled by zope after all (thus triggering authentication
mechanisms) - that's indeed done by telling zope not to re-raise this
particular type of errors.
> Now when you run functional tests this gives you a problem as you expect
> Unauthorized to be there if you set handle_errors to false, but now it
> isn't. Is that correct? I think that's a bug, as handle_errors to false
> means we never want to handle any errors in the publisher, including
> unauthorized. The tests should be run in a way so that when
> handle_errors is False, the reraising behavior is turned off entirely.
> Now somehow a feature to add to debug.ini those errors we don't want to
> reraise helps with this issue. Why?
> The missing idea in my mind is that we wouldn't configure this reraise
> exception behavior in ZCML at all anymore. Instead we'd only put it in
Right. We would remove the IReRaise adapter registration for
IUnauthorized from Grok's configure.zcml again. Instead, the factory
function that creates the zope WSGI app is instructed to register this
adapter for the types of exceptions that you do not want to have
re-raised in debug mode.
So, as a result, only in the case of using the debug.ini profile this
adapter is registered and in all other cases the exception handling
behaviour is just as it was before.
> That sounds reasonable.
> +1 for going ahead with that approach. Feel free to reuse some of the
> above text for the documentation/upgrade notes.
I'll try to work on this tonight and tomorrow to get this in properly fixed.
Thanks for reviewing.
More information about the Grok-dev