OK then, what does this script print?

Sadly, I don't have access to this particular server, and particular hosting account. I'm trying to answer the questions of a user of mine. They've basically given up on my program, because of the FrontPage problem. I can't be the only person having this problem with perl scripts/programs they distribute. Thought I'd start my homework here, after doing the obligatory google search, which didn't really give me any leads.

The reason why you should not put the modules in cgi-bin is that you most likely do not want people to download or execute them, do you? If your scripts are to be installed in $foo/cgi-bin then the libraried may well be in $foo/lib. Thus you'd just use lib qw(../lib); instead.

In my experience, any file that doesn't have a fileending of, ".pl", or, ".cgi", that's located in the cgi-bin, doesn't get executed as a cgi script. This is ultimately based on the Apache (in this case) server config.

That's one safegaurd.

Another is the lack of a shebang line in perl modules - what is the server supposed to run the file as? Usually on the first line (instead of the shebang line), you declare the name of the perl module itself, correct? Something like: 

package FooBar;

[download]

Thirdly, cgi scripts usually have to have their permissions changed to 755 to execute through the web browser.

What usually happens when you visit a perl module in a browser, is that you get a Server 500 error. I have seen, in rare circumstances (let's say, .01%), the sourcecode of the package itself get printed out. But, since this program is open source, let the code be free! :) Your example of using Cwd may move the lib dir into the public html directory. Usually apache is set up to map any unknown filetype to a text/plain mime type - which means, you'll def. see the sourcecode. Also, I don't think you can call use like your example shows: 

 

use Cwd;use lib cwd()."/../lib";

[download]
perhaps: 
 

use Cwd;
require lib cwd()."/../lib";

[download]
Looking for the current working directory also doesn't turn up what you expect in cgi scripts. I know the, $ENV{HOME} variable is usually not given.

I may be wrong.

If any and all these safegaurds fail, on Apache servers (the target platform, again), usually an .htaccess file, with: 

 
deny from all

[download]

in the lib directory will do the trick.

Or, am I missing something else?

Finally, I look at the London Perl Mongers effort on the nms-scripts program - which, as they state, is a rewrite of poorly written cgi scripts, done by professionals, with security def. in mind. They've consciously used their efforts to show how perl cgi scripts are supposed to be written.

As just one example, I looked at a program called, "TFMail", which is a basic form handler, and a replacement for the ubiquitous, "FormMail.pl" script.

It's a simple program, that does use outside .pm perl packages to get its job done. the location of these packages can be set in the program itself. The documentation of the program does state (emphasis mine)

You must also copy NMStreq.pm and MIME_Lite.pm to the server. You should put them in the location that you configured for LIBDIR above. Leaving LIBDIR set to '.' and uploading the .pm files into your cgi-bin directory will work on most UNIX systems.

So, it doesn't seem like these self-proclaimed professionals (of which are undoubtably much smarter than I am), don't see much of a problem. If you see a problem, you may want to tell them they have a bug on their hands.

So, I think I make a good argument for the placement of Perl packages in a cgi-bin. I'm having trouble with FrontPage making strange directories and weird configuration files, with the same names of the perl packages and mucking up my program. And, I'm looking for a workaround (moving them out of the cgi-bin is something I already stated in the initial post, I think)

Sorry if I've come off like I don't know what I'm doing - I don't have any formal training, but Perl was made to hack, as I was lead to believe, and it's lead me to work as well as I can, from what I know with it. I've got a few years under my belt, but I feel like I'm being replied to as if I haven't a clue and this prentension just saddens me, because it doesn't do much for the popularity of Perl.

 

-justin simoni
skazat me

In reply to Re^4: MS Frontpage, _vti_cnf directories and perllibs by skazat
in thread MS Frontpage, _vti_cnf directories and perllibs by skazat

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.