Your Netmar account gives you unlimited access to Netmar's SSL secure server.
To access a document through SSL, simply address it as follows:
https://www.netmar.com/~USERNAME/file.html
OR
https://www.netmar.com/users/USERNAME/file.html
where USERNAME is your login name (in lowercase), and file.html
is the file located in your "www" directory.
Any other items reference in this file with relative links also go through
the secure server. This includes CGI scripts as well. So if the file were an
HTML form, and the action were just "/cgi-bin/...", then that script
would be called securely.
On pages referenced AFTER a secure transaction, BE SURE to use absolute links
to point the browser back to an http:// address (instead of staying on https://)
as otherwise, browsers will continue to browse your site over the secure server,
which is considerably slower than plain access due to the overhead of processing
encryption.
Creating imagemaps is
an easy way to make your web page more interesting without having to expend a
lot of effort or become entangled in complex technical issues. An imagemap consists
of two files - a graphic file which forms the backdrop for the map and the map
file which points the different parts of the image to different URL's.
You can designate any image as an imagemap by inserting the ISMAP keyword
in your IMG tag, and enclosing the tag inside of an anchor that point to your
map file.
For an example, and detailed instructions on setting up your map file, look
at the manual page for
imagemap.
CGI scripts have been the subject of many misunderstandings among those who are
new to the 'net as well many who are more experienced. CGI stands for common gateway
interface, and it is just that - a gateway for certain html documents to pass
information to programs which can process it and return data that can be viewed
by a web browser.
Your Netmar account gives you access to several general-purpose CGI script
which are commonly used, as well as allowing to upload or create your own CGI
scripts through the use of the cgiwrap
program, which, as the name implies, wraps itself around the scripts in a user's
directory, allowing these scripts to run as if the user had run them directly.
To run a CGI script located in your cgi-bin directory (just off your home
directory), you execute the following URL:
http://netmar.com/ucgi-bin/USERNAME/SCRIPTNAME
or http://netmar.com/cgi-bin/cgiwrap/USERNAME/SCRIPTNAME
where USERNAME is your login name (in lowercase), and SCRIPTNAME
is the name of the script located in your cgi-bin directory. You may substitute
your own Virtual Server's domain name for netmar.com in the above example.
One useful script is our SecureCard system,
which allows for secure transmission of credit card information across the World
Wide Web.
If you would like to learn how to write CGI scripts, or are having problems
getting yours to work properly, you might want to take a look at this CGI
Primer.
Since the hardest part of a CGI script is the actual handling of form data,
we have included a couple of links to sites that have information regarding
form data.
If you're looking to turn the output of an HTML form into email, then go no further
than the system-wide mail script.
Netmar offers one of the most robust and feature-laden FORM-to-Email gateway
programs available anywhere on the Internet. The Mail script can process the
output of an HTML form, check it against a set of rules to determine whether
or not it should be accepted, convert into one or more formatted email messages,
and return a formatted response to the browser, complete with data from the
form embedded within. It can then repost all of the given data to ANOTHER script
for special processing. If that sounds like too much, and you just want to mail
a simple form, it can do that too. The Mail script is available by setting your
FORM ACTION tag equal to "/cgi-bin/mail"
In addition, there are a number of special variables which tell the script
how to operate.
Here is a sample form that demonstrates use
of all of the mail script's features. Feel free to save and reuse it.
Here are the other files that would go with that form:
mailform.etemp - Used to create the formatted
email message.
no_email.phtml - Shown when no email or
an invalid email is entered.
no_url.phtml - Shown when no URL or an invalid
URL is entered.
no_cc.phtml - Shown when no credit card number
or an invalid number is entered.
Synopsis:
The FORM tag must be as follows: either <FORM ACTION="/cgi-bin/mail" METHOD="POST">
or <FORM ACTION="/cgi-bin/mail" METHOD="GET">
All variables must be defined in your form in one of two ways:
Input Type Hidden - This allows you to embed values into your form that
don't change. <input type="hidden" name="VARIABLE" value="VALUE">
Input Type Text - This inserts an input box which allows the user of the
form to specify the value of the variable. <input type="text" name="VARIABLE">
Select - This inserts a drop-down menu that allows the user to choose from
a list. <select name="VARIABLE">
<option> Option 1
<option> Another option
</select>
Variables:
Refer to this example to see how
these are actually used in a real form.
to(required)
Must be set to the destination email address to which contents of the form
should be sent.
cc
Any additional email addresses to which the email message should be sent.
next
The URL or file that will be the "next hop" after the form is submitted.
This can either be a URL (starting with http://...), or a local HTML file
with or without subcodes. This file should be specified with either its full
path (/users/j/johndoe/www/whatever.phtml) or by the full path starting from
the DocumentRoot directory of your Virtual Server. For instance, if your Virtual
Server points to /users/j/johndoe/www/domain, and your file were
located in /users/j/johndoe/www/domain/dir/file.phtml, then you
would specify "/dir/file.phtml" as the value of this variable.
If a file is specified, the file is parsed and the values of the other
variables in the form may be inserted in the file before output using an
advanced parsing engine. See the mail
system manual page for details.
If a URL is specified, no parsing is possible. If a file is specified,
make sure you use absolute links
within it.
If not specified, mail will present a default page that says "Message
Sent" and has a link that points to the root of the Virtual Server
on which the form was located.
emailtemplate
File to be used as a template to construct the outbound email message. Data
from the form can be inserted using subcodes (just like the file specified
by next). For more info on the parsing engine and how subcodes
work, see the mail
systeam manual page. This file starts in the header of the email
message. This means that the first line of the file is a mail header.
The mail header continues until the first blank line. There must
be a blank line to separate the header from the body. Typically,
The first line would be just the Subject: header. So a template file would
start off with a line that reads:
Subject: ${subject}
followed by a blank line. Do not forget to have a blank line after
the headers. If you do, your message will fail.
subject
The subject of the form. The value of this variable is used in the subject
line of the generated email message if you don't use an email template.
confirm
A return (origin) email address, and a file to be used as a template to
send an email message to the person filling out the form at the address he/she
supplies in the "email" field of the form. The template used follows
the exact same parsing conventions as that specified by the "emailtemplate"
variable.
pgp
Value is of the form "username; keyid"
Consists of a username, a semi-colon, and a PGP User ID. The username tells
PGP whose public keyring to search. The PGP User ID tells PGP what public
key to find in the keyring. The public key is then used to encrypt the body
of the email message, which may then only be decrypted by the person(s) holding
the corresponding private (secret) key. This encryption allows for the sending
of highly sensitive information via email, such as personal and financial
information typically accompanying product/service orders.
name
The name of the person submitting the form. This variable would typically
be set using an input box of type text, allowing the submitter to enter their
name. It is used to set the name of the sender on the outbound email message.
email
The email address of the person submitting the form. This variable would
typically be set using an input box of type text, allowing the submitter to
enter their email address. It is used to set the email address of the sender
on the outbound email message so that the message can be replied to.
require
Value is of the form "variable variable; file"
A require rule tells mail not to send any mail if any of the variables listed
before the semicolon do not contain any data. If the rule is not satisfied,
the file or URL specified after the semicolon is sent instead.
is_email
Value is of the form "variable variable; file"
An is_email rule tells mail not to send any mail if any of the variables listed
before the semicolon do not contain properly formatted Internet email addresses.
If the rule is not satisfied, the file or URL specified after the semicolon
is sent instead.
is_web
Value is of the form "variable variable; file"
An is_web rule tells mail not to send any mail if any of the variables listed
before the semicolon do not contain properly formatted WWW addresses. If the
rule is not satisfied, the file or URL specified after the semicolon is sent
instead.
is_ccard
Value is of the form "variable variable; file"
An is_ccard rule tells mail not to send any mail if any of the variables listed
before the semicolon do not contain a credit card number that passes standard
mathematical checksums. This does NOT check to see if the card is active or
even exists. Rather, it just checks to see if the number can be used as a
valid credit card number. If the rule is not satisfied, the file or URL specified
after the semicolon is sent instead.
bgprocess
The URL of another script to which the contents of the form should be posted.
This allows you to have the contents of a form mailed to you AND processed
by your own script without requiring the user to fillin two forms. To protect
against loops, the name of the bgprocess variable is changed to "_bgprocess"
before the post is done. Method POST is always used regardless
of how the mail script was originally called. The repost is done in the background,
and the reponse from the specified script is discarded.
fgprocess
The URL of another script to which the contents of the form should be posted.
This allows you to have the contents of a form mailed to you AND processed
by your own script without requiring the user to fillin two forms. To protect
against loops, the name of the fgprocess variable is changed to "_fgprocess"
before the post is done. Method POST is always used regardless
of how the mail script was originally called. The repost is done in the foreground,
and the response from the specified script is sent directly to the browser,
as if the mail script generated it. When fgprocess is used and
a valid URL is specified, the next variable is completely ignored.
If you are unclear on any of this, you may wish to see this Forms
Tutorial to learn more about HTML forms.
Server Side Includes (SSI)
Apache HTTPd allows users to create documents which provide simple information
to clients on the fly. Such information
can include the current date, the file's last modification date, and the size
or last modification of other files. In its more advanced usage, it can provide
a powerful interface to CGI and /bin/sh programs.
Documents that have Server-Side Includes within must be designated as such.
They should either 1) end in .shtml or 2) have the user execute bit set. This
can be done by logging in via telnet and typing "chmod u+x filename" at the
"netmar>" prompt.
Your Netmar account allows you to create per-directory ACF's, or Access Control
Files, to limit who can access certain HTML
documents and how they can be accessed. This can be done by creating a .htaccess
file. This file is made up of directives which are specified below.
Password Protecting an Area
The most common use of per-directory ACF's is for password protecting an area
of your web site. This requires only a few of the access directives. They are:
AuthUserFile FILENAME
FILENAME is the filename with full path (e.g. starting with /users) that
specifies the location of the password file for this area.
AuthName TEXT
TEXT is whatever prompt text you want to appear in the password box.
Exactly how this will be shown depends on the browser, but most browsers
simply show a box that says something to the effect of, "Enter password
for" and then whatever text you enter here.
AuthType Basic
This is required and should be entered in your .htaccess file as-is.
This is the sectioning directive. It works just like HTML in that there
is also a tag to denote the end of this section. This should be entered
just as above.
require valid-user
This is the access requirement the server will observe for this area.
and should be entered INSIDE the LIMIT section. The word "valid-user"
tells the server that it must be a username/password combination appearing
in the password file specifed by your AuthUserFile directive. Other requirements
may also be specified. See the require directive in the
list below.
Click here to see an example of an ACF for password
control along with step-by-step instructions for creating the password file
itself.
Directives
This is a list of the directives
and sectioning directives used when writing an ACF. Each directive specifies
where it can be used, and gives examples of usage. Parameters to these directives
must be enclosed in "double quotes"
This is a very popular option for your Netmar account. The virtual server makes
it appear to the rest of the web that you have your own dedicated web server.
In the "olden" days, if you got a web page, and then registered
your own domain name, your URL
just became http://yourdomain.com/yourdomain, and if someone
left off the end part, and just typed in http://yourdomain.com,
they actually ended up staring at your provider's homepage!.
The Virtual Server did away with all that, allowing http://provider.com
and http://yourdomain.com to be served out of two completely separate directory
trees, even though both are on the same physical machine.
To use a virtual server you must first have a domain name registered with
InterNIC, which is the organization
responsible for keeping track of all domain names on the world
wide web.
To register, simply go to the online template.
The template is accompanied by detailed instructions available as links on
how to fill out the appropriate sections. Having filled out the template,
you then send it to the Netmar staff, and we create the virtual host and complete
the registration process. This can take anywhere from two days(if the template
is properly filled out) to eight weeks (if there are mistakes or omissions
which require human reviewers). However, once the registration is complete,
your virtual server will be up and running, complete with its own domain name
and corresponding IP address.
You can create email aliases in your virtual server by using the .aliasmap file.
The details on how to configure this file can be found in the alias manual page.
Another feature of your Netmar Virtual server is that you can create your own
custom error document to be displayed when web
browsers look for a page that doesn't exist. To do this, simply create a
file called 'default-error.html' in the document root directory of your virtual
server. NOTE: This is a simple html file. Simply make it like any other Web
page, except this one is to tell the user that they went to an incorrect site.
