And don't forget to configure things so it is turned on in development and off in production. Else you'll provide an ideal tool to help attackers debug their attacks against any flaws that they find in your site. | [reply] |
| [reply] |
I'm not sure I really agree with this. While most of my applications are for internal customers (and so I don't worry too much about the point tilly raised), it seems to me that if you have a lot of warning chaff in your logs, the solution is to fix the warnings, not suppress them. I generally leave CGI::Carp directives like 'FatalsToBrowser' in effect for my web apps -- I'd much rather my internal customers get an intelligible error message than something less helpful, if only so that when they e-mail me about it, I can start thinking about the cause of the problem immediately (without sifting through the logs). I think it also helps my customers to see that when errors happen, they're for a reason (and sometimes are because of other dependent systems, and therefore not entirely my fault). :)
Of course, OfficeLinebacker may have been talking more about suppressing debug stuff, which can be configured nicely with things like Log::Log4perl.
| [reply] |
| [reply] |
I strongly disagree with this.
Don't silence the messenger. Leave warnings and debugging on. Actively clean up warnings so that you don't have any spurious warnings. Monitor what remains.
You'll find that a significant fraction of the time the warnings you get will point to bugs that slipped past development and QA. Often enough to justify the rest of the work.
| [reply] |