>>>>> "Drieux" == Drieux <[EMAIL PROTECTED]> writes:
Drieux> just a quick knickle tour - I of course will defer to Randal
Drieux> to go into more detail if required.
That covers most of it, but let me put it a different way.
"use CGI::Carp qw(fatalsToBrowser);" presumes that the person
operating the browser is the person also developing the program.
While this can certainly be true during development, it is rarely
true (if ever!) in production.
Here's the problem:
The end user doesn't want to see a Perl error message. They will
probably have no clue what to do to work around it, and will rarely
understand how to precisely copy that error (and any associated state
or sequence descriptions) to a proper email buffer to email the
developer.
But worse, the end user *shouldn't* see the details of the error,
which will often include filenames and other key data that might
reveal the security mechanisms being used. This is prime intrusion
vector information - a goldmine for the person wanting to abuse the
website.
All you should do for a non-recoverable error is tell the user:
SOMETHING WENT WRONG.
WE ALREADY KNOW ABOUT IT.
IF YOU WANT TO TELL US WHAT YOU WERE DOING:
email [EMAIL PROTECTED] referencing trouble ticket #12345.
and then on the server side, log the hell out of the error, and create
a trouble ticket so there can be a repair made and correlation with
any user. If you don't want to create a "ticket", just use
unpack("H*", pack "NS", time, $$), which should be fairly unique and
yet short enough to cut and paste nicely.
In fact, that'd be nice column idea! I needed one for TPJ today.
Thanks.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
