Andre_br has asked for the wisdom of the Perl Monks concerning the following question:

Hello folks

Iīve been wondering about having any way to direct the die's to my email too, besides to the browser, what I already do.

Anyone there has already done that? Is there a module for that?

Thanks

Andre_br

Replies are listed 'Best First'.
Re: Carp: Fatals to my email
by skx (Parson) on Sep 25, 2005 at 16:22 UTC
      Thatīs exactly the recipe I was looking for! Thanks a lot skx!
Re: Carp: Fatals to my email
by tilly (Archbishop) on Sep 26, 2005 at 07:08 UTC
    I hope you're not directing dies to the browser in production code. If you are then stop, because that is a security risk.

    The problem is that the exact same debugging output that helps you figure out how to make a program work how you want it to can help an attacker to make it not work in the way that he wants it to.

    A security hole generally starts off as a way to get your code to do something that it shouldn't. This often means that your code will die. In order to refine this into an attack, the attacker needs to figure out what they are doing that causes your code to misbehave, and needs to figure out how to make your code misbehave in the way that they want. You do not want to assist them in that, which means that you don't want to hand out debugging information.

    The example that I point people to is the "SQL injection attack". In this case people don't properly escape parameters to SQL, and an attacker can then get custom SQL into your database. With debugging output, the attacker can probe to find out what your (now broken) SQL looks like, make it become something that the database will accept, convince the database to cough up information about what it looks like (which database it is is a good thing), and then convince it to cough up its data. (Credit card numbers are a favorite.)

    If you don't provide debugging output, all of this is still possible, but it becomes incredibly harder to do.

      Hey tilly,

      Yeah, I know. On one hand, Iīve built my code a lot against SQL injections and all, but I agree it should be avoided. But then how do you guys get any input from the user? I mean, he will only be able to describe a 500 server error, and not the error message and the precious line anymore. Unless he cares about writting down the exact time of the error - and has a precise clock on his wrist, right?

        That is what servers have error logs for. Look at them. (Then you don't have to rely on the user to assist you in finding errors!)
Re: Carp: Fatals to my email
by aufflick (Deacon) on Sep 26, 2005 at 00:18 UTC
    You need to be careful sending die's in an email. Various international treaties ban hate mail like that ;)
Re: Carp: Fatals to my email
by adrianh (Chancellor) on Sep 26, 2005 at 09:55 UTC
    Anyone there has already done that? Is there a module for that?

    You might want to take a look at logging modules like Log4perl.

      Thanks for the tip, adrianh. But I took a look there and it seems not very easy to implement. Also I donīt know if I can do that being in a shared hosting account, you know?
        But I took a look there and it seems not very easy to implement

        You might find the perl.com article a more gentle introduction.

        Also I donīt know if I can do that being in a shared hosting account, you know?

        The answer depends on whoever is doing the hosting.

        You can ask to see whether it is installed. You can ask to get it installed if it isn't already. Alternatively, since it's a pure perl module, you should be able to just copy it into a local directory and add it in with use lib.