RE: [Zope] Traceback? Codechange!
-----Original Message----- From: Tino Wildenhain [mailto:tino@wildenhain.de] Sent: 29 May 2000 15:44 To: Marcus Collins Cc: 'Chris Withers'; Martijn Pieters; Patrick J.M. Keane; zope@zope.org Subject: Re: [Zope] Traceback? Codechange!
Hi,
[...]
This is very ugly imho. It schould be sufficient, if one includes the traceback-variable into the standard-error where its appropriate. In the current implementation it will break the HTML-standard with code outside <HTML></HTML> and additionally makes it impossible to get error-messages to picky browsers, such as WAP-devices.
I second this -- despite the traceback being sometimes crucial to debug errors, its inclusion after the closing HTML tag goes against the standard. Furthermore, the traceback *could* sometimes be considered to pose a security risk, since it exposes the names of methods in the call stack, some of which should not necessarily be callable through the web. Or am I just being paranoid?
Is it ok if we remove these lines?
I think there should be a knob to turn it off... and not for the whole site, but for a subtree (perhaps even on a folder-by-folder basis). That way, the folks who develop and deploy on a single Zope server (does anyone do this?) can keep their tracebacks on sites under development, but get rid of them on live sites.
Do I have to copy this message to the collector and wait for a couple of months or can we do it instantly? ;-)
*grin*
Regards Tino Wildenhain
-- Marcus
On Mon, May 29, 2000 at 04:08:59PM +0200, Marcus Collins wrote:
This is very ugly imho. It schould be sufficient, if one includes the traceback-variable into the standard-error where its appropriate. In the current implementation it will break the HTML-standard with code outside <HTML></HTML> and additionally makes it impossible to get error-messages to picky browsers, such as WAP-devices.
I second this -- despite the traceback being sometimes crucial to debug errors, its inclusion after the closing HTML tag goes against the standard. Furthermore, the traceback *could* sometimes be considered to pose a security risk, since it exposes the names of methods in the call stack, some of which should not necessarily be callable through the web. Or am I just being paranoid?
Is it ok if we remove these lines?
I think there should be a knob to turn it off... and not for the whole site, but for a subtree (perhaps even on a folder-by-folder basis). That way, the folks who develop and deploy on a single Zope server (does anyone do this?) can keep their tracebacks on sites under development, but get rid of them on live sites.
We should probably switch to error_tb in the default standard_error_message, including detecting if Zope is running in debug mode and using <PRE></PRE> and <!-- --> when appropriate. You can then redefine standard_error_message to exclude the traceback completely if you want to, or only in certain parts of the site. Seeing object names in a traceback doesn't necessarily mean that a site visitor has access to those objects, nor does completely not giving a traceback protect those objects from being called diectly. Only properly configured security settings on those objects themselves gives proper security, and then it doesn't matter wether or not their names are publicly visible.
Do I have to copy this message to the collector and wait for a couple of months or can we do it instantly? ;-)
Do you still experience the Collector as black hole? Could you report this to Tres Savier, the person currently monitoring the COllector and cleaning it out? Thanks! In the meantime, please do report this there, this would be a useful change, if only to let more people understand how to switch tracebacks off.. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | The Open Source Web Application Server ---------------------------------------------
Martijn Pieters wrote:
Do I have to copy this message to the collector and wait for a couple of months or can we do it instantly? ;-)
Do you still experience the Collector as black hole? Could you report this to Tres Seaver, the person currently monitoring the COllector and cleaning it out? Thanks!
It HAS got a lot better since Tres started, but there's still a load of cruft in there; stuff that's not completed but is so old that it's now irrelevant. A small point, could all searches/browsing/etc all be sorted in reverse date order? That way I wouldn't have to trudge through a lot of Zope 1.x problems just to get to the stuff that's relevant. On a more radical thought, there was talk a while back of ditching the collector in favour of a Tracker, whatever happened to that plan? cheers, Chris
On Mon, May 29, 2000 at 04:14:19PM +0100, Chris Withers wrote:
Martijn Pieters wrote:
Do I have to copy this message to the collector and wait for a couple of months or can we do it instantly? ;-)
Do you still experience the Collector as black hole? Could you report this to Tres Seaver, the person currently monitoring the COllector and cleaning it out? Thanks!
It HAS got a lot better since Tres started, but there's still a load of cruft in there; stuff that's not completed but is so old that it's now irrelevant.
A small point, could all searches/browsing/etc all be sorted in reverse date order?
I don't think we are going to make any changes to the collector anymore, see below.
That way I wouldn't have to trudge through a lot of Zope 1.x problems just to get to the stuff that's relevant.
On a more radical thought, there was talk a while back of ditching the collector in favour of a Tracker, whatever happened to that plan?
This is on Ethan's To-Do list at: http://www.zope.org/Tracker/9 and because it is on his list, there is no use in maintaining the old Collector's behaviour. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | The Open Source Web Application Server ---------------------------------------------
participants (3)
-
Chris Withers -
Marcus Collins -
Martijn Pieters