[Grok-dev] Final touches for a 1.0 "proper"

[Jan-Wijbrand Kolman]

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:
>>
>> [app:zope]
>> use = egg:Debugging#debug
>> filter-with = translogger
>> exempt-exceptions = zope.security.interfaces.IUnauthorized,
>>                      some.other.interface.ISomething
>>
>> 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 
> again:
> 
> 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 
unauthorized.

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.

Exactly.

> 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 
> debug.ini.

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.

OK!

I'll try to work on this tonight and tomorrow to get this in properly fixed.

Thanks for reviewing.

regards
jw