in reply to Review of CGI::Alternatives

I agree with separating super-duper HTML production from CGI but it would be useful to have some basic stuff in there for quick printing out something. Maybe freeze existing HTML functionality in CGI.pm and that's it. Forcing templates on people is not the right approach although templates helped my productivity enormously.

Otherwise I agree with the poster. ALTHOUGH I dont have much of commercial experience deploying CGI.pm based apps and bearing the responsibility for security etc. Neither have I built an app and then found that CGI.pm has changed so much that my app is not working anymore and I have to re-write it. I would not like it much either, but that's how the business process in the world is right now: make obsolete and re-write.

Can anyone elaborate on any security risks posed by CGI.pm and if these are solved with alternatives? I kept reading that CGI.pm is insecure and alternatives is the way to go in the modern era ... but can anyone substantiate these claims?

Any other points to compare CGI.pm with alternatives?

Replies are listed 'Best First'.
Re^2: Review of CGI::Alternatives
by trippledubs (Deacon) on Jun 14, 2018 at 19:09 UTC

    I always thought the criticisms against CGI were lame, but using the later tools is so much more enjoyable that it's hard to care all that much. Nothing against OP, do whatever you want.

    List flattening made a guy really mad and he did some videos at a conference. To me, his argument boils down to: List flattening is a bad language design choice because it is easily misunderstood by reasonably well trained programmers. I'm sure there was more, but that is what I got out of it.

    I could not find a video referencing CGI that did not use the f word extensively. Sorry about that. That in itself is kind of funny though.

[reply]

      Through the list of links you posted above I came across this:

      • PacSec Hype Security Team: CGI.pm param injection which from what I understand the vulnerability comes when parsing a request with multiple same-name params. Perl's list/hash idiosyngracies be what they may makes it possible to create a hash of parameters which is not what one had in mind.
      • and then this Re: Stop Using Perl : 
        "... But you know whats even more amazing? They patched CGI.pm to warn about this ..."
[reply]
Re^2: Review of CGI::Alternatives
by Anonymous Monk on Jun 14, 2018 at 23:44 UTC
    Otherwise I agree with the poster. ALTHOUGH I dont have much of commercial experience deploying CGI.pm based apps and bearing the responsibility for security etc.

    It was this false assumption that we're all using CGI.pm in ways that cause Perlmonks to run and hide their children (Matt's) that caused it's ejection from corelist and mutilation on CPAN. These days I usually use CGI::Simple::Standard anyway but CGI was exceptionally handy for writing portable (corelist) local administrative programs that don't endure the Internet. It's also capable of cranking out HTML under control of Perl to create things like dynamic templates and static resources in background processes run by cron that might hit a database once a minute or more to serve static resources rather than let live users make real requests that could range from 0 to Infinity per second... From what I can see there are still 3 modules on the corelist that generate HTML (and a lot more) but only from POD! With templates written in POD the Pod modules can crank out everything from HTML, XHTML, XML, RTF, man, etc. Hopefully they're SECURE! :-)

[reply]

In Section Meditations