[Koha-devel] Re: FAQ: Why am I prompted to save a .pl file? was: Problems adding a biblio...

[MJ Ray]

Rick Welykochy <rick at 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 at 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/