The CGI Bin, Formmail and SSI (Server Side Includes)
CGI-bin Applications
Where to Put CGI-bin Scripts
Paths to Date, Mail, Perl, etc.
Setting Permissions
Setting Permissions Using Fetch For MAC
Setting Permissions Using WS_FTP for Windows
Permission Definitions
Troubleshooting CGI-bin Problems
Cgiwrap--Secure Server CGI Wrapper
Formmail.cgi
SSI Guidelines
CGI-bin Applications
CGI stands for "Common Gateway Interface," a fancy name meaning computer programs running on the web server that can be invoked from a www page at the browser. The "bin" part alludes to the binary executables that result from compiled or assembled programs. It is a bit misleading because cgi's can also be Unix shell scripts or interpreted languages like Perl. CGI scripts need to be saved in ASCII format and uploaded to your server's cgi-bin in ASCII or text format. This is very important.
We do not provide Technical Support for CGI scripts. So if you are not already familiar with CGI scripting, you may want to read a book on the subject or find places on the Internet with CGI scripting information. There are many good resources for CGI scripts found on the web. The scripts at Matt's Script Archive found at http://www.worldwidemart.com/scripts/ are very good. You'll find many scripts free of charge and with detailed configuration information. Another excellent resource is The CGI Resource Index found at http://www.cgi-perl.com/ -- if you are not an expert, look for scripts that are very well documented and come with step-by-step instructions.
Back to the top
Where to Put CGI-bin Scripts
Put your cgi-bin scripts in the www subdirectory named "cgi-bin".
Back to the top
Paths to Date, Mail, Perl, etc.
Here are your paths to the common server resources that CGI scripts often require:
Sendmail: /usr/sbin/sendmail
Perl5: #!/usr/bin/perl
Date: /bin/date
Serverpath: /home/username/domain-www/cgi-bin
Root path: /home/username/
(puts you in your the root of your account)
Domain directory: /home/username/domainname-www
(puts you in your www directory)
Cgi-bin path: /home/username/domainname-www/cgi-bin/filename
(puts you in your cgi-bin)
NOTE: Do not include domain extension anywhere you list your domain name.
Back to the top
Setting Permissions
There are three different ways to set permissions for your files and directories within your account. 1) File Manager, 2) FTP, and 3) Telnet. We DO NOT encourage the use of Telnet if it is only being used for setting permissions and will forego its explanation here.
Setting Permissions Using Your File Manager:
Log into your Control Panel and then click on File Manager. You will now see a list of directories within the root of your account. Since all of your html files and subdirectories are uploaded and created within your www directory you need to click on the directory labeled "www".
Once inside your www folder, you will see, as in all directories, the first column is the Permissions Column, click on the link pertaining to the directory or file that you wish to set the settings for and the Permissions screen will open as seen in the screen shots below. (Refer to Permission Definitions further down this page for an explanation of settings.
Setting Permissions using Fetch for MAC:
If you have Fetch for the Mac, you have an easy way to change permissions. Go to the file you want to change the permissions on, and highlight it. Under the Remote menu, select Change Permissions. A window will pop up showing the current permissions for the file you had highlighted, as shown in the screenshot below. Click on the boxes to change permissions as needed. (Refer to the Permission Definitions further down this page for an explanation of settings.
Setting Permissions Using WS_FTP for Windows:
WS_FTP accomplishes the same task as above. Just highlight the file you want to check, and right-click on it. A menu will pop up, then select CHMOD. You will see the window as shown below in the screenshot we've provided. Click on the appropriate settings as needed. (Refer to the Permission Definitions further down this page for an explanation of settings.Permission Definitions
Owner = the files users (you)
Group = the files group
Others = others
Permissions Definitions:
r = read access
x = execute access
w = write access
Numerical Definitions:
r = 4
x = 2
w = 1
You will come to recognize, if you do not already, Chmod as a word used for changing
Permissions from within Telnet or your FTP client.
Some scripts will tell you to chmod 775 (for example). When using the numeric system, the code for permissions is as follows:
4 + 2 + 1 (rwx) = 7
The first number applies to Owner, the second number applies to Group, and the third number applies to Others. Therefore the first 7 of the chmod 775 tells Unix to change the Owner's permissions to rxw (because r=4 + w=2 + x=1 adds up to 7, this giving the Owner Read, Write, and Execute Permission. The second 7 applies to the group, this giving the Group Read, Write, and Execute Permission, and the last number 5, refers to Others (4 + 1= 5), giving Others only Read and Execute Permission. The permissions for chmod 775 look like this: rwx rwx -rx.
Permissions are always broken up into three groups of letters, however if there is a dash, this dash simply means that Permission wasn't given for that particular function, for example in the chmod 775, Permission to Write was not given to Others.
Remember: the first 3 letters always apply to Owner, the second 3 apply to Group, and the third 3 apply to Others.
Troubleshooting CGI-bin Problems
Below are solutions to some of the more common CGI script problems, in question
and answer format. You will find a list of proper permission settings for the scripts
we provide at the end.
When I activate my CGI program, I get back a page that says "Internal Server
Error. The server encountered an internal error or mis-configuration and was unable
to complete your request."
This is generally caused by a problem within the script. Log in via Telnet and test
your script in local mode to get a better idea of what the problem is. To do this, go
into the directory in which your script is located, then execute the script. To
execute the script, you can do it by two ways:
1) Type "perl myscript.pl" (Perl being the language interpreter in this case).
2) Or simply type "myscript.pl" alone, that will work if the first line is well written to
indicate the location of Perl.
The first one is useful to see if there's any error IN your script. The second one is
useful to test if your "calling line" (the first line of the script) is okay, i.e. if you
entered the right location of Perl.
I am being told "File Not Found," or "No Such File or Directory."
Upload your Perl or CGI script in ASCII mode, not binary mode.
When I test my Perl script in local mode (by Telnet), I have the following error:
"Literal @domain now requires a back slash at myscript.pl line 3, within string.
Execution of myscript.pl aborted due to compilation errors."
This is caused by a misinterpretation by Perl. You see, the "@" sign has a special
meaning in Perl; it identifies an array (a table of elements). Since it cannot find the
array named domain, it generates an error. You should place a back slash (\)
before the "@" symbol to tell Perl to see it as a regular symbol, as in an email
address.
I am getting the message "POST not implemented."
You are probably using the wrong reference for cgiemail. Use the reference
/cgi-bin/cgiemail/mail.txt. Another possibility is that you are pointing to a cgi-bin
script that you have not put in your cgi-bin directory. In general, this message
really means that the web server is not recognizing the cgi-bin script you are
calling as a program. It thinks it is a regular text file.
It's saying I don't have permission to access /
This error message means that you are missing your index.htm file. Note that files
that start with a "." are hidden files. To see them, type ls -al. If you wish to FTP
this file in, go to the home/yourdomain directory.
Back to the top
Cgiwrap - Secure Server CGI Wrapper
We now have a cgi wrapper for the secure server called cgiwrap. We have
configured it to be automatically invoked when you make a call containing
"cgi-domain", like this:
https://secureservername/cgi-domain/script.cgi
You can call cgiwrap explicitly with this call, which does the same thing as the
above call:
https://secureservername/cgi-bin/cgiwrap/domain/script.cgi
This assumes script.cgi is in your cgi-bin. You can also use cgiwrapd in place of
cgiwrap to get extra debugging information if there is a problem. For nph-style
scripts, use nph-cgiwrap or nph-cgiwrapd instead.
Back to the top
Formmail.cgi
FormMail is a generic www form to e-mail gateway, which will parse the results of
any form and send them to the specified user. This script has many formatting and
operational options, most of which can be specified through the form, meaning you
don't need any programming knowledge or multiple scripts for multiple forms. This
also makes FormMail the perfect system-wise solution for allowing users
form-based user feedback capabilities without the risks of allowing freedom of CGI
access.Configuring the FormMail Script. (Download this file: Formmail.pl)
The FormMail.pl script does not have to be extensively configured in order to work. There are only two variables in the perl file which you will need to define along with changing the top line of your script to match the location of your Perl interpreter. Which is /usr/bin/perl for our server.
$mailprog = '/usr/sbin/sendmail'; This variable must define the location to your server's sendmail program. If this is incorrect, form results will not be mailed to you.
@referers = ('yourdomain.com','IP Address'); This array allows you to define the domains that you will allow forms to reside on and use your FormMail script. If a user tries to put a form on another server, that is not yourdomain.com, they will receive an error message when someone tries to fill out their form. By placing yourdomain.com in the @referers array, this also allows www.yourdomain.com, ftp.yourdomain.com, any other http address with yourdomain.com in it and yourdomain.com's IP address to access this script as well, so no users will be turned away.
Uploading the FormMail Script.
The next step is to upload the file to your cgi-bin using FTP or Telnet in ASCII mode. Once the file is uploaded you must CHMOD the file to 755. (For more on how to do this, please see "Setting Permissions" in Chapter 11).
Using the Script
There is only one form field that you must have in your form, for FormMail to work
correctly. This is the recipient field. Other hidden configuration fields can also be
used to enhance the operation of FormMail on your site. The action of your form
needs to point towards this script (obviously), and the method must be POST in
capital letters.
Here's an example of the form fields to put in your form:
<FORM METHOD=POST ACTION="http://yourdomain.com/cgi-bin/formmail.cgi">
<input type=hidden name="recipient" value="whoever@yourdomain.com">
<input type=hidden name="subject" value="Order">
<input type=hidden name="return_link_url"
value="http://yourdomain.com/htmlpage">
<input type=hidden name="return_link_title" value="htmlpage">
The following are descriptions and proper syntax for fields you can use with
FormMail.
Recipient Field:
Description: This form field allows you to specify to whom you wish for your form
results to be mailed. Most likely you will want to configure this option as a hidden
form field with a value equal to that of your email address.
Syntax: <input type=hidden name="recipient" value="email@yourdomain.com">
Subject Field:
Description: The subject field will allow you to specify the subject that you wish to
appear in the email that is sent to you after this form has been filled out. If you do
not have this option turned on, then the script will default to a message subject:
"WWW Form Submission".
Syntax: If you wish to choose what the subject is:
<input type=hidden name="subject" value="Your Subject">
To allow the user to choose a subject:
<input type=text name="subject">
Email Field:
Description: This form field will allow the user to specify their return email address.
If you want to be able to return e-mail to your user, I strongly suggest that you
include this form field and allow them to fill it in. This will be put into the From: field
of the message you receive. If you want to require an email address with valid
syntax, add this field name to the 'required' field.
Syntax: <input type=text name="email">
Realname Field:
Description: The realname form field will allow the user to input their real name.
This field is useful for identification purposes and will also be put into the From: line
of your message header.
Syntax: <input type=text name="realname">
Redirect Field:
Description: If you wish to redirect the user to a different URL, rather than having
them see the default response to the fill-out form, you can use this hidden variable
to send them to a pre-made HTML page.
Syntax: To choose the URL they will end up at:
<input type=hidden name="redirect" value="http://yourdomain.com/to/file.html">
To allow them to specify a URL they wish to travel to once the form is filled out:
<input type=text name="redirect">
Required Field:
Description: You can require certain fields in your form to be filled in before the user
can successfully submit the form. Simply place all field names that you want to be
mandatory into this field, separated by commas. If the required fields are not filled
in, the user will be notified of what they need to fill in, and a link back to the form
they just submitted will be provided.
To use a customized error page, see "missing_fields_redirect"
Syntax: If you want to require that they fill in the email and phone fields in your
form, so that you can reach them once you have received the mail, use the syntax
like:
<input type=hidden name="required" value="email,phone">
Env_report Field:
Description: Allows you to have Environment variables included in the email
message you receive after a user has filled out your form. Useful if you wish to
know what browser they were using, what domain they were coming from or any
other attributes associated with environment variables. The following is a short list
of valid environment variables that might be useful:
REMOTE_HOST - Sends the host name making the request.
REMOTE_ADDR - Sends the IP address of the remote host.
HTTP_USER_AGENT - The browser the client is using.
(Note: In our case, both REMOTE_HOST and REMOTE_ADDR are the same,
since our servers don't do the reverse DNS look up needed to generate the true
REMOTE_HOST string).
Syntax: If you wanted to find all the above variables, you would put the following
into your form:
<input type=hidden name="env_report"
value="REMOTE_HOST,REMOTE_ADDR,HTTP_USER_AGENT">
Sort Field:
Description: This field allows you to choose the order in which you wish for your
variables to appear in the email form that FormMail generates. You can choose to
have the field sorted alphabetically or specify a set order in which you want the
fields to appear in your mail message. By leaving this field out, the order will simply
default to the order in which the browsers send the information to the script (which
is usually the exact same order as they appeared in the form).
When sorting by a set order of fields, you should include the phrase "order:" as the
first part of your value for the sort field, and then follow that with the field names you
want to be listed in the email message, separated by commas.
Syntax: To sort alphabetically:
<input type=hidden name="sort" value="alphabetic">
To sort by a set field order:
<input type=hidden name="sort" value="order:name1,name2,etc...">
Print_config Field:
Description: print_config allows you to specify which of the config variables you
would like to have printed in your e-mail message. By default, no config fields are
printed to your email. This is because the important form fields, like email, subject,
etc. are included in the header of the message. However some users have asked
for this option so they can have these fields printed in the body of the message.
The config fields that you wish to have printed should be in the value attribute of
your input tag separated by commas.
Syntax: If you want to print the email and subject fields in the body of your
message, you would place the following form tag:
<input type=hidden name="print config" value="email, subject">
Print_blank_fields Field:
Description: print_blank_fields allows you to request that all form fields are printed
in the return HTML, regardless of whether or not they were filled in. FormMail
defaults to turning this off, so that unused form fields aren't emailed.
Syntax: <input type=hidden name="print_blank_fields" value="1">
Title Field:
Description: This form field allows you to specify the title and header that will
appear on the resulting page if you do not specify a redirect URL.
Syntax: If you wanted a title of 'Feedback Form Results':
<input type=hidden name="title" value="Feedback Form Results">
Return_link_url Field:
Description: This field allows you to specify a URL that will appear, as
return_link_title, on the following report page. This field will not be used if you have
the redirect field set, but it is useful if you allow the user to receive the report on the
following page, but want to offer them a way to get back to your main page.
Syntax: <input type=hidden name="return_link_url"
value="http://yourdomain.com/index.htm">
Return_link_title:
Description: This is the title that will be used to link the user back to the page you
specify with return_link_url. The two fields will be shown on the resulting form page
as:
Syntax: <input type=hidden name="return_link_title" value="Back to Main Page">
Back to the top
SSI that is not allowed:
EXEC CMDThe simplest example of server-parsed HTML is to have a file "foo.shtml" containing this text:
Line one
<!--#exec cgi="mycgi.cgi" --><P>
Line three
And then have a file "mycgi.cgi" that contains, on Unix:
#!/usr/bin/perl
print "Content-type: text/htmlnn";
print "Line Two";
And when you access "foo.shtml", it will output:
Line one
Line two
Line threeIf your include directive is <!--#exec cgi="..." -->, then the cgi program you run must output a standard CGI header (Content-type: text/html)
Any file named foo.shtml will be parsed automatically by Apache on our servers.
Do not put any spaces before the '#' character in your include directives; if you have "<!C- #exec" instead of "<!C-#exec", the line will be ignored.
Server-side includes in "custom trailers" will not work, since custom trailers are appended to the output of your web pages after all other processing has been done on them. Any server-side includes that you put into your custom trailers will be sent directly to the browser without being parsed.
More Help for using SSI can be found at:
http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html
