in reply to Security question

Thanks for all of the input. This is a misapprehension that I've labored under for a while.

In fact, now that I'm rereading the source for that SSI information, it specifically lists this as a problem with scripts that create static HTML pages.

tilly: thanks for the link. A hardcopy is sitting on my desk now. Amusingly enough, that comment about "they do not even die on failed opens" is particularly frustrating. Two days ago, I went down to an technical bookstore and scanned about 4 books dealing with Perl and CGI. Not one of those books were consistently checking return codes on file opens. That, of course, is in addition to all of the typical problem: no strict, -w, or -T. And these people are touting themselves as professionals!!! Some of them clearly know Perl better than I (which isn't hard to believe), so it was dismaying to see such dangerous programs being listed.

It's a sad, sad, world.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.

Replies are listed 'Best First'.
RE (tilly) 2: Security question
by tilly (Archbishop) on Oct 09, 2000 at 19:51 UTC
    When I first saw that I was shocked and dismayed.

    Then I thought about it.

    The problem is fundamental. One of the great shortcomings of a CGI environment is that there is not a great standardized error reporting scheme. If you die, that only gives an informative message if you have CGI::Carp or some equivalent installed. Is it the place of CGI.pm to discuss where to find your error logs? Another solution is centralized error reporting, but that is a site decision.

    Without a standardized way to display meaningful errors, there is no good way to trap them. And CGI.pm cannot assume a good standardized way to display them. Hence there is a catch-22.

    What I think is a good solution is to somewhere have a good online tutorial and then have CGI.pm point out the issue and direct people to that tutorial. Said tutorial will need to discuss options for error reporting and decide on one very early. Then use it consistently.

    The books, OTOH, have no excuse. A book is a format which (like a tutorial) can cover error reporting early, settle on an option, then use it consistently in the examples.

RE: (Ovid) Re: Security question
by merlyn (Sage) on Oct 09, 2000 at 19:35 UTC
    Almost any book with both "PERL" and "CGI" in the titles (yes, capitalization is significant here) is worthless. Or if they call it "Perl 5". Instant clue of lack of clues.

    -- Randal L. Schwartz, Perl hacker