Rick Welykochy <rick@praxis.com.au> wrote:
MJ Ray wrote:
What we should do is make the errors prettier. We should probably use CGI::Carp qw(fatalsToBrowser); - is that OK by everyone and do we need this only in C4::Output or in all cgi-bin scripts?
This is okay, but it does present a security concern, since internal details of the Perl environment and MySQL could be revealed with the dumped errors.
What details dumped could be exploited? Chris mentioned testing this - what would a Koha error actually dump? I tried it with a silly example and it looks like we just get this by default: Software error: aiee at /home/mjr/webapps/sites/koha/intranet/cgi-bin/mainpage.pl line 17. For help, please send mail to the webmaster (info@ttllp.co.uk), giving this error message and the time and date of the error. So as long as no-one is putting passwords into their die messages (which would be a bug already, because the password would appear in logs), then I think it looks like we should be OK. Also, note that we can configure and/or subclass CGI::Carp to pretty up the message and suppress sensitive info.
In my experience, system and internal errors are for "programmers eyes only".
In my experience, Koha sysadmins aren't finding the system and internal errors, so they never reach the programmers' eyes. How many times do we post some variation of "check koha-error_log" to the koha lists? How many people don't do that? How many bugs are going unfixed because we're not making it easy for people to send us good bug reports the first time?
Would you want these errors to be displayed on the browser of an OPAC user?
No. They should be disabled when putting the system into production, or maybe OPAC should be configured differently. I think I want these errors to be displayed on the browser of a Librarian Intranet user, and displayed on the OPAC during setup and testing. This would get us straight past the "what is the problem?" stage and onto "why has this happened?" [...]
Fatal errors are raised as exception via die and can be caught via eval. Exceptions (i.e. fatal error processing) are indeed very modern Perl programming techniques.
So by exceptions, you did not mean exceptions as such. Thanks for clarifying. The manual entry for die suggests using Carp, which is what I suggested too. Using core perl modules seems far safer than relying on everyone remembering on wrapping everything that can go wrong in an appropriate eval{}. Sod's law says that an error would occur outside the eval{} anyway. I'm slightly scared that you have re-invented that wheel and then used that re-invention in large-scale ecommerce systems. Why aren't you using the Carp modules or something based on them? Puzzled, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Experienced webmaster-developers for hire http://www.ttllp.co.uk/ Also: statistician, sysadmin, online shop builder, workers co-op. Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/