[Grok-dev] debug.ini breaks the admin ui

[Uli Fouquet]

Hi there,

Jan-Wijbrand Kolman wrote:
> Martijn Faassen wrote:
> > Hi there,
> > 
> > If you install Grok besides the issue of getting the wrong version of 
> > grokui.admin, it also doesn't work when you use debug.ini. That doesn't 
> > actually help the installation experience either.
> > 
> > When I go to localhost:8080 instead of seeing the admin screen I see an 
> > error page (because the system raises Unauthorized).
> > 
> > I still believe that we should make debug.ini ignore Unauthorized and 
> > NotFound and actually let them be interpreted properly by Zope. These 
> > are not exceptions we want to debug.
> 
> +1
> 
> However, wasn't that exactly the problem - the 
> exception-catching-middleware interfacing with zope has no way of 
> declaring what exceptions *not* to catch?

That's the point. Even if the debugger-middleware had such a feature
like 'dont-catch = Authorized' it wouldn't help much, as when such an
exception is 'received' by the debugger (we're acting in a WSGI
pipeline), we cannot force the Zope middleware to ignore this exception
anymore. We had to reinject the whole request to Zope adding: handle
errors yourself this time.

> If I understood correctly it is actually a limitation in zope where you 
> can only turn off zope's exception handling completely or have it turned 
> on (this is actually something one can do in ftests as well, i.e. with 
> the test browser, where one can say "browser.handleErrors = False" that 
> gets passed on to zope).

Right. With the debugger-middleware enabled we say: pass exceptions
(_all_ exceptions) to the next item in the WSGI pipeline. I see no way
to tell Zope: "pass only the following exceptions: ...". The Zope
component responsible for this is zope.publisher, BTW.

> In other words, the debug.ini complaints are directed to somewhat the 
> wrong party - even though I agree the enduser experience is bad and 
> should be improved; maybe should remove the debug.ini alltogether and 
> first see the issue fixed in zope (and/or the exception middleware 
> whatchamacallit).

Thanks for that clarification, JW! More in-depth analysis of the problem
can be found in the bug report:

   https://bugs.launchpad.net/grok/+bug/332061

I think we simply cannot fix this quickly. A fix that made grokui.admin
redirect automatically to the login page was refused by Martijn. So we
would need a different zope.publisher to handle it, probably something
one wants to avoid this so short before 1.0.

So it looks like the two options are: 

* go with debug.ini and make users know about the working login 
  procedure (which exists) or 

* just skip debug.ini.

If we skip it, nothing can stop users from using a self-created
debug.ini and the same problems will appear. There will only be less
documentation about it, which might be an even worse user-experience. We
will only hide away the problem. Therefore I intentionally kept
debug.ini in last `grokproject` release.

What I would like to know: What _is_ the real user experience with it?
What do _you_, the users of Grok, prefer?

Would you prefer to get rid of debug.ini, so you're not tempted to use a
debugger middleware which requires a special login procedure?

Or would you better like to have an 'online-debugger' available even if
you had to go to @@login.html first?

Best regards,

-- 
Uli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20090418/0b8816f1/attachment.bin