in reply to @ symbol in html output

Whenever you get 500 internal server errors you can easily ensure you get the actual text of the error in the browser for you to read by adding this code to the top of your script. This makes diagnosis a snap. Actually you can add it anywhere because of the BEGIN block. For more CGI tricks see my CGI Help Guide. It also explains how this works for you.

You will be getting the 500 error because Perl will be spewing that you need to \ you @ chars in strings. This error comes out before the valid header and thus you get the error 

# ensure all fatals go to browser during debugging and setup
# *don't* uncomment these 5 lines on production code for security
BEGIN {
    $|=1;
    print "Content-type: text/html\n\n";
    use CGI::Carp('fatalsToBrowser');
}

[download]

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Replies are listed 'Best First'.
Could you explain the importance of this line from your post?
by jerrygarciuh (Curate) on Sep 23, 2001 at 22:12 UTC
    # *don't* uncomment these 5 lines on production code for security
    TIA
    jg
[reply]
      It wasn't my post, but the reason is simple. The hook in question will make errors go to the browser in a fairly informative fashion. This aids development. But if someone is trying to attack your site, the debugging output will help them break in.

      It is kind of like leaving a note saying where the key is hidden.

      That said, the actual style given there of having lines of code you modify between development and production is not the way you should do it. Instead what you should do is have a very small module that has those lines. Install that module in your development environment. Then in your production environment have a different version of the module that doesn't do anything. That way you don't have to touch your code going from development to production, and nothing will mess up. Otherwise your development process will be constantly complicated by the need to track down things like those lines which have to be edited at the last moment before going live, lines which you could introduce errors on. This will be an ongoing source of work and problems.

      Many here will recognize this as an example of an abstraction layer. Instead of writing in development hooks through your code, you write an abstraction layer for turning on the optional hooks. That abstraction layer will do the right thing for your evironment without your having to change a lot of source code going from one environment to another. The idea of solving problems with abstraction layers rather than scattered checks is a key one in good programming. I talk about it a bit at RE (tilly) 2: Handling cascading defaults (abstraction is great!) among other places.

[reply]
      They enable extra debugging outfit that's helpful for programmers. Unfortunately, it can be confusing for normal users and may even be exploitable by malicious users. It gives out more information that anyone but the people who have access to the error logs really need to know.
[reply]

In Section Seekers of Perl Wisdom