[Grok-dev] debug.ini breaks the admin ui
uli at gnufix.de
Sat Apr 18 06:43:49 EDT 2009
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.
> 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
Thanks for that clarification, JW! More in-depth analysis of the problem
can be found in the bug report:
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20090418/0b8816f1/attachment.bin
More information about the Grok-dev