in reply to Perl Obsfucate Or Encrypter

This is probably a bad approach, but I can't personally see why so maybe wiser monks can inform?

What if... the CGI is just a wrapper program? It takes the parameters, passes them along to another PERL script which does the real processing and returns a nice long HTML string. The CGI program receives the string, prints it back to the browser and... presto! Code is hidden! There will be a cost in maintenance complexity and in performance. But, aside from those issues are there any hidden "gotcha" issues that make that approach unwise?

-Tats

Replies are listed 'Best First'.
Re: Re: Perl Obsfucate Or Encrypter
by Mr. Muskrat (Canon) on May 29, 2003 at 19:40 UTC
    Read How can I hide the source for my Perl program?. If someone can read the source of your CGI script, they can read the source of the script that the CGI calls (meaning they have access to the system via a means other than the web browser).
[reply]

      The FAQ you listed didn't seem to say anything about that, did I miss it?

      Either way, can't you get around that by calling the script via backticks (``) or through a system call? If you call a C program via system or backticks does that reveal the object-code to the calling script too?

      -Tats
[reply]
[d/l]
[select]

        You missed the section that contains this key line: (That doesn't mean that a CGI script's source is readable by people on the web, though, only by people with access to the filesystem)

        But you are missing the point too. The source of a CGI script can only be viewed by people with sufficient access to the file system. They have to have shell or local access to view the source code. (Unless you have hosed your web server configuration!) So there is no point in running a script through another script before sending the output to the browser.

[reply]

In Section Seekers of Perl Wisdom