|
Server
Paths and support Manual
CGI
Scripts, FormMail and SSI
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
Here are your paths to the common server resources
that CGI scripts often require:
Sendmail: /usr/sbin/sendmail
Perl5: #!/usr/bin/perl
Serverpath: /home/username/public_html/
Root path: /home/username/
(puts you in your the root of your account)
Domain directory: /home/username/public_html
(puts you in your www directory)
Cgi-bin path: /home/username/public_html/cgi-bin/filename
(puts you in your cgi-bin)
Date: /bin/date
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.
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.
-
Setting
Permissions Using Telnet/SSH:
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.
-
-
Examples
of using chmod:
People:
u = the file's user (you)
g = the file's group
o = others
a = the user, the group, and others
|
Permissions:
r = read access
x = execute access
w = write access
|
To change permissions for a file named filename.cgi, you need to
chmod the file (change mode). For example, when you type this:
chmod u=rwx,g=rx,o=rx filename.cgi
by typing this you have given:
read, execute, and write access to the user (that's you)
read and execute access to the group and;
read and execute access to others
Some scripts will tell you to chmod 775 (for example). Doing the
above is the same thing as typing chmod 775. You can use either
method with our Unix servers. Let me explain:
When using the numeric system, the code for permissions is as follows:
r = 4 w = 2 x = 1 rwx = 7
The first 7 of our chmod 775 tells Unix to change the user's permissions
to rxw (because r=4 + w=2 + x=1 adds up to 7. The second 7 applies
to the group, and the last number 5, refers to others (4+1=5).
When doing an ls -l on the file, telnet always shows the permissions
this way:
-rwxr-xr-x
Ignore the first dash, then break up the above into three groups
of letters. If there's a dash where a letter should be, it means
that there is no permission for those people.
Remember: the first 3 apply to user, the second 3 apply to group,
and the third 3 apply to others.
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.
Back to the top
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.
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 ACTION = "/cgi-sys/formmail.pl" METHOD = "POST"> <input
type=hidden name="recipient" value="ANYONE@YOURDOMAIN.COM"> <input
type=hidden name="subject" value="SUBJECT"> <input type=hidden
name="return_link_title" value="TITLE"> <input type=hidden
name="redirect" value="http://YOURDOMAIN.COM/PAGE.HTML">
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:
Back to Main Page
Syntax: <input type=hidden name="return_link_title" value="Back
to Main Page">
Back to the top
Server Side Includes (SSI)
What is SSI?
Used properly, the SSI
can help make your pages more responsive and can even help make
maintaining your site an easier task.
Put simply, SSI is sort
of like using your HTML server as a cut and paste editor. Here is
basically what happens when your server handles a request for an
SSI document. If you use SSI, you must rename the page so that it
ends in .shtml so that the server knows to parse the page for SSI
commands.
- The server reads
the document and parses (techie word for chops up and looks
for special instructions) it for directives. (another techie word
for directions!)
- Follows the instructions
that it finds and merges their results into creating a finished
document.
- The document is
then sent to the client browser.
SSI also seems to be one of the better
kept secrets around. In any web related book, they seem to get about
1 page for every 200 pages on CGI and FORMS. Well, I've never been
one to leave you in the dark when it comes to being a better webmaster.
How to Use SSI
The syntax of an SSI
include is as follows:
<!--#include file="mailform1.txt"
-->
Where mailform1.txt
is the path to the file that you want to be included. For instance
if you have a file called file.shtml and you include the SSI
<!--#include file="mailform1.txt"
-->
The contents of mailform1.txt
will be displayed in file.shtml.
There are many good tutorials
in SSI available on the Web. Here are a few that we recommend:
|
|
