Once you've learned how to use the Protect directive to restrict access via username and password it will be easy to learn about an additional capability, restricting pages to anyone from certain IP addresses. This can provide a way to allow certain groups of people to access pages without requiring them to enter a username and password but disallowing other groups.

If you were an ISP and wanted to allow only your dial-in PPP customers to have access to certain web pages but wanted to disallow access to the Internet in general you could use this form of protection scheme. Local users wouldn't have to log in, and Internet users would be blocked.

In these examples we will demonstrate how to restrict access to your whole site. The first tutorial demonstrated the techniques used to restrict access to a certain directory or set of directories. Those techniques are valid for accessing via IP address. For clarity this tutorial will assume that you are trying to restrict access the whole site.

Allowing a single IP address to access your site

Here is a protect rule that allow everyone coming in from the IP address 123.123.123.009 to access any of your web pages:

Protect /* {
	GET-Mask	@123.123.123.009
}

Any user coming from that computer will be allowed access without having to log in. All other users will be blocked from the site.

Allowing a list of IP addresses to access your site

Protect /* {
	GET-Mask	@123.123.123.009,@123.123.123.030
}

Allowing a block of IP addresses to access your site

In this example all IP addresses from 123.123.123 are allowed to access the site

Protect /* {
	GET-Mask	@123.123.123.*
}

Allowing different blocks of IP addresses to access your site

In this example all IP addresses from 123.123.123 and 123.123.123 are allowed to access the site.

Protect /* {
	GET-Mask	@123.123.123.*,@123.123.123.*
}

Restricting access by domain name

NOTE. To enable protection by domain name you must set the following parameter in the SY:HTTPD.CON file.

dnslookup On

This will tell the web server to perform domain name translation. This is normally disabled for performance reasons. You should be aware that this will be performed on each web page request, and will add a not-insignificant amount of overhead to the request.

Allowing all users at a domain name to access your site

Protect /* {
	GET-Mask	@aol.com
}

Allowing all users at some domain names to access your site

Protect /* {
	GET-Mask	@*.edu
}

Allowing a list of domain names to access your site

Protect /* {
	GET-Mask	@*.jpl.nasa.gov,@*.sandh.com
}

Allowing certain users who are from certain addresses to access your site

You can also combine names and addresses in conjunction with the password file, introduced in the previous tutorial, to allow only certain people at certain IP addresses or domain names have access to your site.

This works by combining the two conditions: The IP address (or domain name) must match and the person must log in with a username and password that are stored in the password file.

Before going further, lets explore more deeply what it means to allows access to a user at an IP address or domain name. Does this mean that the web server "knows" who the authorized users on those systems? No, it doesn't. It is nothing more complex than performing two checks, in order, before allowing access to web page. First the domain name, or the IP address, is verified. As mentioned, this does not perform any prompting of the client. Then, because a username was specified as part of the GET-Mask directive, the client is prompted for a username and password combination. The local password file is consulted. If a match is found, the page is passed back. The list of usernames and passwords in the password file represent the set of valid combinations that allow access to web pages. There is no connection whatsoever with the usernames and passwords in the local file and any other system anywhere.

Here is an example that only lets the user mott from S&H computers log into your site. Notice that we now have to specify the name of the password file. This is how the web server will know that the user mott is authorized to access the system.

If you're not certain how this password file is to be used, review the first tutorial where it is described.

Protect /* {
	PassWdfile  	/__c__/pwfile.dat
	GET-Mask	mott@*.sandh.com
}

Protect /* {
	PassWdfile  	/__c__/pwfile.dat
	GET-Mask	mott@*.sandh.com,dan@*.ccicomputing.com
}