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 chmod775 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:
http://secureservername/cgi-domain/script.cgi
You can call cgiwrap explicitly with this call, which does the same thing as the
above call:
http://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
| IMPORTANT: As of
7/12/2002 we have made our form mail scripts more secure by requiring a '.recips'
file in the CGI-BIN directory. Simply list any email addresses
that this form mail script will send email to in
your '.recips' file. Please include any '@yourdomain.com'
addresses as well as all those that are off-network.
Here's an excerpt from the email which notified our clients of the
change:
"If the script is called from the global cgi-sys, it checks to see
if any of the recipients' domains are on the local machine. If they are,
then the information in the form is sent to the recipients' email address.
If you want to send the information in the form to an "offsite"
email address, you will have to create a link from the cgi-bin to the
global formmail.pl script. Then you need to create a '.recips' file in
your cgi-bin directory. It is a "hidden" file, which means that
it will not show up in your File Manager but "can" be created
and accessed through your File Manager. You will be able to enter
"offsite" email addresses in this file. If you are sending the
information on the form to several different email addresses and one of
them is either "off" the server or not listed in the '.recips'
file, none of the email addresses listed as recipients will receive the
information on the form. All the email addresses used as recipients on the
form must either be on the server or listed in the '.recips' file.
What all this means is that the email address that the form information
is sent to must be on the local machine (your server) or must be listed in
the '.recips' file. This will stop spammers from accessing your sendmail
through the formmail script and will stop them from sending out email with
the recipient's email address as their own."
|
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 ofr 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:
http://bignosebird.com/ssi.shtml
http://usats.com/learn/ssi.shtml
http://www.ora.com/info/cgi/ch05.html