Skip to main content

Search this Site

DartPulse Alerts

"HeartBleed" Website Security

Java Upgrade

Windows XP Alert

 

DartPulse Outages

Overall System Status:

Upcoming Scheduled Outages

New to Dartmouth?

Resources for:

Information Security

Connect with Computing

facebook twitter Wordpress Blog

Adding Features to Your Web Pages

Adding "mailto" Links

You can create a link that sends e-mail to you by using the a mailto: URL. These URLs have the form of mailto:my.name@somewhere.edu where you insert the real e-mail address after mailto:. You would code a mailto: URL in HTML as follows:

Be sure to <A HREF="mailto:my.name\@somewhere.edu">send me a note!</A>

In addition to the recipient's e-mail address, you may need to specify other mail header lines such as cc, the subject, and the body of the message in the URL. For example, the following URL sends a message to a mail address, with the subject line of current-issue:

mailto:infobot@ghjk.com?subject=current-issue

The URL below sends to the same e-mail address, but places the text send current-issue in the body of the message:

mailto:infobot@ghjk.com?body=send%20current-issue

You may include multiple headers in a mailto: URL by separating the header parts with an ampersand (&). For example:

mailto:infobot@ghjk.com?body=send%20current-issue&subject=please%20send%20current%20issue

Note that many characters in a mailto: URL need to be specially encoded. The list includes:

%20: Space or blank
%3F: Question mark (?)
%3E: Equal sign (=)
%27: Ampersand (&)
%0D%0A: Line breaks (i.e., a carriage return followed by a line feed)

A more complete description of the various options and encodings of the mailto: URL is available from its specification. The current version is always available from ftp://ftp.near.net/internet-drafts/. To get the right document, do a find for mailto.

Top of page

Collecting Data From Web Forms

If you publish web pages, you can use web forms to collect data from those who browse your pages. There are several different methods for collecting this information, the most popular of these is to have the collected data sent to you by e-mail. This works well for low-volume data, such as requests for information. This is straightforward to set up. The remainder of this page describes the process.

This information explains how you can add forms to your pages and have the data returned to you. (Your HTML files must be stored on the server www.dartmouth.edu for these instructions to work.) To set up a form on a page you publish, follow these step-by-step instructions.

  1. Create a page that will have the form in it. Using the HTML editor of your choice, draw up an HTML document, leaving space where you want the form to appear.
  2. Add our example HTML code to your page. Below is an example of an HTML form. We have provided the HTML code for you to copy into your own web pages.
  3. Once you have the example HTML code on your web page, edit the code. The directions with the sample show you exactly what you need to change.
    1. It includes your e-mail address so you can receive the results by e-mail.
    2. It includes form elements that ask users for the data you are seeking.
  4. Upload the page to www.dartmouth.edu and view it. It should show the complete form. Clicking Submit should send your e-mail.

Sample of An HTML Form

Input Your Name

Your Gender:

Female

Male

Other

Select your Favorite Food:

Your Address:

HTML Code For the Example Form

Copy the following text from your Browser window into your text editor. Replace the portions in bold with your own information!

<!-- This command starts the form -->
<form method="post" action="http://www.dartmouth.edu/cgi-bin/form-handler.cgi">
<p>
<!-- This command specifies a URL that will be shown to the user after submitting the form. (Optional) -->
<input type="hidden" name="URL" value="http://web.dartmouth.edu/~account/result-page.html">
<p>
<!-- This command specifies a mail address that will receive the form results. -->
<!-- To specify multiple recipients, separate their e-mail addresses with a comma. -->
<input type="hidden" name="MAILTO" value="your-name@dartmouth.edu">
<p>
<!-- When you receive the results of the form by email, you can specify a distinctive Subject header that the results should contain. -->
<input type="hidden" name="SUBJECT" value="Form Results!">
<p>
<!-- With those out of the way, you can now specify your form elements! -->
<!-- These are sample form elements. -->
Input Your Name <input type="text" name="name" value="Fred"></p>
<p>
Your Gender:
<dl>
<dd><input type="radio" name="Gender" value="Female"> Female<br>
<dd><input type="radio" name="Gender" value="Male"> Male<br>
<dd><input type="radio" name="Gender" value="Other" checked> Other<br>
</dl>
<p>
<p>
Select your Favorite Food:
<select name="food">
<option>Cabbage
<option>Eggplant
<option>Parsnip
<option>Rutabaga
<option>Scallions
<option>Yams
<option>None of these
</select>
</p>
<p>
Your Address:
<textarea name="Address" rows=4 cols=40>
Kiewit Computation Center
North Main Street
Hanover, NH 03755
</textarea>
<p> <!-- A submit button, so the user can send off the form. -->
<input type="submit" value="Submit Form">
<!-- A reset button, to clear the form. (Optional) -->
<input type="reset" value="Clear This Form">
<p>
</form> <!-- This command closes the form. -->

There are many other types of form elements that we have not used here. BBEdit for the Macintosh is a useful HTML authoring tool that includes shortcuts to create many of them. Information is available from many online sources to show you how you can create forms!

Top of page

Searching Within Your Site

You may use the Ultraseek search engine licensed by Dartmouth College to create a search service within your site. Searches will be limited to pages that are part of your website.

To do this, include the following text in your HTML web page. Replace unique-string with a string that appears only in URLs of your web pages. For example, you might include your account name as the search string (i.e., /~apply).

<form name="seek" method="get"
             action="http://search.dartmouth.edu/query.html">
<input type=hidden name=qp value="+url:unique-string">
<input type=hidden name=qs value="">
<input type=hidden name=qc value="">
<input type=hidden name=ws value="0">
<input type=hidden name=qm value="0">
<input type=hidden name=st value="1">
<input type=hidden name=nh value="10">
<input type=hidden name=lk value="1">
<input type=hidden name=rf value="0">
<input type=hidden name=oq value="">
<input type=hidden name=rq value="0">
<input type="text" name="qt" size="15" value="" maxlength="200">
<input type=submit value=" Search ">
</form>

This will place a text field and input button (labeled Search) on your page. It will look similar to the one below:

Entering text into the field will cause the Dartmouth College website to be searched. Only web pages that match the string you entered and whose URLs contain the unique string will be displayed. The example above has web/features as the unique-string, and thus, will only find pages in this section about adding features to your website.

Top of page

Using Server Side Includes

A "server-side include" is a function performed by a web server that embeds (includes) information into the middle of an HTML file as it is being sent to the web client. This is convenient for inserting the current time or the file's size into your HTML document without resorting to writing a CGI. It is also useful for placing common headers and footers (such as copyright notices, addresses, and other boilerplate items) on a set of pages.

Most books about the web provide information about server-side includes. For more information, see Apache Tutorial: Introduction to Server Side Includes.

Using Server-side Includes at Dartmouth

To use a server-side include, the including document must have a suffix of .shtml. This suffix is a hint to the server that it should parse the file and perform the includes as directed.

Wherever a file is to be included in your HTML file, include a comment of the form <!--#include virtual="somefile.html" -->. Note that the comment delimiter (<!--) must be immediately followed by the word #include without intervening spaces.

There is also a #include file="..." command, but the named file must be a relative path and may not include ".." (referring to a parent directory).

Dartmouth's main web servers (on www.dartmouth.edu and Cobweb) support several other commands, including echo, fsize, flastmod, and config. For more information about these commands, see Apache Tutorial: Introduction to  Server Side Includes or the examples below.

Documents named index.shtml may be the default for a directory. Dartmouth's web servers search for a document named index.html, and if it is not found, it will use index.shtml.

Dartmouth's web servers do not support the exec, daycnt, totcnt, or lastzero commands.

Examples

You can include the date a document was modified by using the command <!--#echo var="LAST_MODIFIED" -->. The default format of the date is Friday, 23-May-97 10:31:19 EDT.

You may alter the format of the output to meet your needs by using the config command. For example, <!--#config timefmt="%d %B %Y" --> will change the date format shown by the above echo command to 23 May 1997.

Top of page

Redirecting Users to a New Web Page

It is possible to configure your website to redirect requests for certain URLs using Apache's Rewrite module.

When a request for a particular URL arrives at a web server, the server normally returns the file named in the URL. Sometimes, it is desirable to have the URL redirected to an entirely different page or to a CGI. Below is an example of this on Dartmouth's website:

  • The Web Calendar page (http://www.dartmouth.edu/calendar) also invokes a CGI that displays the event of the current day.

All these redirects occur using a mechanism provided by the Apache web server called rewrite rules. The web server examines an arriving URL to see if it matches any patterns specified by the rewrite rules. If there is a match, the URL is internally rewritten to create a new URL for the desired page.

This page shows you how to create rewrite rules at Dartmouth.

To continue with one of the examples above, the Web Calendar home page is http://www.dartmouth.edu/calendar/. The rewrite rule for that page says that a URL matching that pattern should be rewritten to invoke the CGI below:

http://www.dartmouth.edu/cgi-bin/cgiwrap/calendar/cal

How to Set Up Rewrite Rules

All rewrite rules are contained in a file called .htaccess. The rewrite rules cover all the files in the directory that contain the .htaccess file. Rewrite rules have the form:

RewriteEngine on # this tells the Web server to allow rewriting for this directory
# comment to describe the first pattern to look for, and how to rewrite it
RewriteRule first-pattern-to-look-for the-replacement-text [R]
# comment to describe a second pattern to look for, and how to rewrite it
RewriteRule second-pattern-to-look-for the-replacement-text [R]
...

In general, each RewriteRule line specifies a pattern to look for and replacement text. The patterns can be very complicated — the rules have the full power of UNIX Regular Expressions (i.e., grep), but the example shown below will help most people.

Rewrite Rule Example

If you want to rewrite a particular page (say, a page called somepage.html in a directory) to go somewhere else, then specify a rewrite rule similar to the one  below:

RewriteEngine on
# command to rewrite 'somepage.html' to go to ~otherdirectory/index.html
# include the date & your initials
RewriteRule ^somepage.html$ http://www.dartmouth.edu/~otherdirectory/index.html [R]

This instructs the web server to look for URLs in this directory that have the word somepage.html. If a match is found, then it will internally substitute that text with http://www.dartmouth.edu/~otherdirectory/index.html and re-examine the URL. This causes the index.html page of ~otherdirectory to be displayed. The ^, which indicates the pattern (somepage.html), must begin at the start of the string. The $ indicates that the pattern must end at the end of the string. This prevents other files (such as wholesomepage.html) from matching the pattern and causing a rewrite.

Although they are optional, you should always include the comment lines (they begin with #) so that people can understand the rewriting rules you have created.

The [R] in the rewrite rule shown above tells the web server to redirect the user's browser to the new URL. This is useful because the browser will show the new URL, and creating a bookmark will always lead to the new location.

Leaving the [R] off the line will also display the new URL, but a bookmark saved from the resulting page will continue to use the original (non-rewritten) URL. This would be useful if you wanted to preserve an easy-to-remember URL, but also wanted the ability to change it in the future.

For More Information

If you would like to use rewrite rules, but are unsure of how they work, send e-mail to webmaster@dartmouth.edu.

Ralf Engelschall, the author of the Rewrite module, and Christian Reiber wrote a nice tutorial about rewrite rules in the December 1996 issue of iX multiuser multitasking magazine, published by Verlag Heinz Heise GmbH & Co KG.

The full definition of the rewrite rules is included in the Apache Rewrite Module documentation.

Top of page

Limiting Access to Your Web Pages

Ordinarily, users anywhere on the Internet can view pages you post on Dartmouth's web servers. There may be times though when you may want to restrict access to certain pages to Dartmouth users only, so those outside the dartmouth.edu domain cannot view them. The recommended method for controlling access to your web pages is by using Web Authentication (WebAuth). Although Kerberos at Dartmouth is being phased out, you may want to use Dartmouth's Kerberos authentication software to restrict your pages further to certain groups of Dartmouth users if you have not moved over to using WebAuth (see Controlling Access with WebAuth below).

The following information tells you how to restrict access to your web pages at Dartmouth.

Limiting Access

If you have a folder of web pages stored in your account that you want to protect, you will need to put a special text file called .htaccess in the directory. (The name of the file must be in all lower-case letters.)

Installing this file will protect all the files in that directory, so you should organize your files so all the files you need to protect are in a separate directory from your public files. (Or more than one directory, if necessary.)

The Basic Procedure

You will need to install a file called .htaccess (all lower-case) in the directory you want to protect.

# You can precede comment lines with a # character.
# You should list what accesses to allow and deny.
# This example denies access to everyone who is not
# in the .dartmouth.edu domain (not on the Dartmouth
# campus or not dialed into Dartmouth's network).
# This protection applies to ALL FILES in the
# folder it is placed in.
# There can be no space between the < and the
# word LIMIT, nor between the last word in the tag
# and the >

<Limit GET>
    order deny,allow
    deny from all
    allow from .dartmouth.edu
    allow from 129.170.
    allow from 10.
</Limit>

The important lines are bracketed by the <limit> ... </limit> tags:

  • The deny from all command specifies that all host names and addresses will be denied access to the page in the directory.
  • The allow from command specifies a list of DNS host names or IP addresses that will be allowed access.
  • The order deny, allow command specifies the order in which the deny/allow commands are processed.

In this example, GET access is denied to all browsers in the third line, then the next three lines allow access from any browser with a dartmouth.edu host name, an IP address of 129.170.x.x (which is Dartmouth's public address range), or an IP address of 10.x.x.x (which is Dartmouth's private address range).

More Information

For more information on access control, go to the Apache Server page Authentication, Authorization, and Access Control. Please note that the information on this page, above the Access Control section, does not apply to www.dartmouth.edu and Cobweb. Only the IP/Domain access control is supported.

Top of page

Controlling Access with WebAuth

You can restrict a web page such that only authorized users are allowed access. This service is available on the www.dartmouth.edu, cobweb.dartmouth.edu, and webapp.dartmouth.edu web servers. Restriction is accomplished by creating an .htaccess file, just like in the standard Limiting Access procedure, in the folder that you want to protect.

When a user attempts to access a file in a protected folder, they are automatically routed through the WebAuth login procedure. Once they have logged in, they are returned to the same URL, and their login credentials are then compared against the rules you have specified in the .htaccess file. If they match one of the rules, they are allowed to view the page; otherwise, they are denied. You will find the rule definitions on this page, along with a couple of examples to show how they are used.

For in-depth technical details about the WebAuth system, see Web Authentication at Dartmouth.

WebAuth .htaccess Rules

The WebAuth rules are based heavily on the old Kerberos/SideCar rules. In fact, if you have an older set of rules using the Kerberos/SideCar directives, those will continue to function as WebAuth authentication rules. However, it's recommended that all such rules be updated to use the WebAuth rule directives.

WebauthAllowRealm <realm>

This specifies an authentication realm that can access the protected folder. All users, once they log in to WebAuth, are assigned to a realm, based on the name/password (or PKI certificate) they used to authenticate. That realm is then compared with the realm specified in this rule to see if they are allowed access.

Multiple WebauthAllowRealm rules are allowed, one per line, in the .htaccess file. Valid realms are dartmouth.edu, dartmouth.org, and hitchcock.org.

Note: Using this rule will block access by non-personal accounts, so if you want to allow departmental or organizational accounts to access the protected content, please use the following rule.

WebauthAllowEntireRealm <realm>

This rule works exactly the same as the above rule, but allows access by all valid login accounts present in the realm. This includes departmental and organizational account logins.

WebauthAllowUser <user@realm>

This specifies an individual user who is allowed to access the protected folder. Once a browser user has logged in, the WebAuth system then compares both the user's name and their realm to see if there is a match. As with the previous rules, multiple WebauthAllowUser rules are allowed, one per line, in the .htaccess file. Specified user names must return a unique match or the name directory lookup will fail and the user will not be allowed access.

WebauthAllowUID <UID #>

One of the fields present in the Dartmouth Name Directory (DND) system is called the UID. This is a number that's guaranteed to be unique for an individual user, throughout their entire time at Dartmouth. While name changes are rare, they can and do happen. By using this rule, it's possible to specify the allowed user by their unique number, so that even if a name should change, that user will still be uniquely identified and allowed to access. Using this rule, over the WebauthAllowUser rule, takes a bit more effort to look up each user's UID, but results in a more robust set of authentication directives for your protected folder.

WebauthRequireValidUser

Sometimes you want to protect information such that any person that can log in to the WebAuth system can access it, but you don't really care to know who the person is or what realm they are from. This rule will force a user to authenticate themselves, but as long as they can successfully do that, the system will then allow them access. This rule is most appropriate if you find yourself specifying all three realms with WebauthAllowRealm rules. You can accomplish the same result with a single use of this rule.

Note: If you restrict a web page, you will not be able to validate the web page via a validation service. Also, restricted web pages can not be indexed by Dartmouth's web search engine.

Example 1

If you have a web page that you only want users at Dartmouth to look at, put an .htaccess file in the folder that contains the web page with this rule:

WebauthAllowRealm dartmouth.edu

If someone from outside of the dartmouth.edu realm tries to view any pages in this folder, they will be denied access.

Example 2

Assume you have a folder on your website with sensitive information in it, and in that folder you place an .htaccess file with these rules:

WebauthAllowUser James.Wright@dartmouth.edu
WebauthAllowUser throckie@dartmouth.edu
WebauthAllowUID 58789

Theoretically, the above .htaccess file will allow the user James Wright at Dartmouth College, someone named throckie affiliated with Dartmouth College, and the user matching the UID of 58789, to access any web page in that folder. Let us go through this sample .htaccess file line-by-line.

If James Wright tries to access any page in the folder, he will be sent through the WebAuth login procedure. Assuming he successfully logs in, he will be redirected back and allowed to access the requested pages.

Per rule 2, the .htaccess file will allow the user throckie in the realm dartmouth.edu to access the folder, since only one entry for throckie exists in the DND. But if the College hires another person with the name throckie, or if someone adds that as a nickname, this will cause the rule to fail. To ensure a good name match, you should always specify the full name (firstname.middlename.lastname@realm) of the person when using the WebauthAllowUser rule.

Per rule 3, if the user with UID 58789 logs in to access the page, they are immediately let through. These types of number-based matches are almost always easier for computerized systems to make. Yes, we had to perform a DND lookup on the person (in this case, we're using the test user Throckmorton P. Scribblemonger, aka, throckie), but you can see how it's simpler to use just the UID, rather than Throckmorton.P.Scribblemonger@Dartmouth.edu.

Both rule 2 and rule 3 are giving access to the same user, but we wanted to show the differences between those two WebauthAllow rules.

Combining WebAuth With PHP

The software that makes the above .htaccess rules work with the WebAuth authentication system also provides a benefit to PHP programmers.

Any PHP using pages in a folder/directory that is secured using one or more WebauthAllow... rules gets full access to the authenticated user's profile. All you need to do is access any of the following $_SERVER variables:

REMOTE_USER_FULLNAME -> The full name of the authenticated user.
REMOTE_USER_REALM -> The user's realm.
REMOTE_USER_UID -> The UID.
REMOTE_USER_DID -> The user's Dartmouth ID, normally found on their Dartmouth ID card.
REMOTE_USER_AFFILIATION -> The authenticated user's affiliation. This allows you tell if it's an individual or a department/organization.

Top of page

Using Kerberos to Limit Access

You can restrict a web page such that only authorized users are allowed access. This service is available on the www.dartmouth.edu and Cobweb Web servers. Restriction is accomplished by creating an .htaccess file, just like in the standard Limiting Access procedure, in the folder that you want to protect.

When a user attempts to access a file in a protected folder, the Web server contacts SideCar on their computer to get their Kerberos ticket and compares it against the rules you have specified in the .htaccess file. You will find the rule definitions on this page, along with a couple of examples to show how they are used.

Note: Because Kerberos is being phased out, it is recommended that new pages needing access control work with the Controlling Access with WebAuth section above.

If you have questions about using Kerberos authentication at Dartmouth, see How Do I Configure My Computer to Authenticate Using Kerberos?, or e-mail: webmaster@dartmouth.edu.

Kerberos .htaccess Rules

SidecarAllowRealm <realm>

Specifies a Kerberos realm that can access the protected folder. Any user whose Kerberos ticket is in the realm is allowed access.

Multiple SidecarAllowRealm rules are allowed, one per line, in the .htaccess file. Valid realms are dartmouth.edu or hitchcock.org.

SidecarAllowUser <user@realm>

Specifies an individual user who is allowed to access the protected folder. The user's Kerberos ticket must be in the realm specified. The user is looked up in the appropriate name directory, either the DND (Dartmouth Name Directory) or the Dartmouth-Hitchcock Name Directory to verify usage of the user's full name.

Multiple SidecarAllowUser rules are allowed, one per line, in the .htaccess file. Specified user names must return a unique match or the name directory lookup will fail and the user will not be allowed access.

SidecarLogfile <full path to logfile>

Specifies where DND lookup information is to be logged. No file-specific information is logged; just how many times the DND was accessed per lookup.

This is useful for performance testing only.

Note: If you restrict a web page, you will not be able to validate the web page via a validation service. Restricted web pages will not be indexed by Dartmouth's Web search engine.

Example 1

If you have a web page that you only want users at Dartmouth to look at, put an .htaccess file in the folder that contains the web page with this rule:

SidecarAllowRealm dartmouth.edu

If someone from outside of the dartmouth.edu realm tries to view any pages in this folder, they will be denied access.

Example 2

Assume you have a folder on your Website with sensitive information in it, and in that folder you place an .htaccess file with these rules:

SidecarAllowUser James.Wright@dartmouth.edu
SidecarAllowUser hoyle@dartmouth.edu
SidecarAllowUser smith@hitchcock.org

Theoretically, the above .htaccess file will allow the user James Wright at Dartmouth College, someone named hoyle at Dartmouth College, and someone named smith who works at Hitchcock to access any web page in that folder. Let us go through this sample .htaccess file line-by-line.

If James Wright tries to access any page in the folder, he will be asked for his DND name and password. Assuming he successfully enters them into the Kerberos dialog box, he will be authenticated and allowed to access the requested pages.

Per rule 2, the .htaccess file will allow the user hoyle in the realm dartmouth.edu to access the folder, if only one entry for hoyle exists in the DND. But if the College hires another person with the name hoyle, or if someone adds the name hoyle as a nickname, this will cause the rule to fail. You should always specify the full name (firstname.middlename.lastname@realm) of the person you want to allow access to when using the SidecarAllowUser rule.

Per rule 3, if any user named smith tries to access the folder from Hitchcock, they will be denied access to the folder since the name smith does not return a unique match in the Hitchcock name directory. The failed attempt to access the folder would be logged to any specified error file.

Combining Kerberos With PHP

The software that makes the above .htaccess rules work with Kerberos/SideCar authentication also provides a benefit to PHP programmers.

Any PHP using pages in a folder/directory that is secured using one or more SidecarAllow... rule can access the name of the authenticated user. All you need to do is access $_SERVER ['REMOTE_USER'] to get the authenticated user's name.

Note: Because the Kerberos 5 system is built into Mac OS X, it is possible for the authenticated user's name to not be their full DND name. This is especially true when using SidecarAllowRealm. However, the authenticated name does have to be unique to that user, so it would be possible to perform a DND lookup on the $_SERVER ['REMOTE_USER'] value to obtain the user's full DND name. The PHP-to-DND code will be made available soon.

Top of page

Last Updated: 3/14/11