|
ACCESS CONTROL This section describes how to limit access to your server based on IP addresses and/or passwords. There are sets of data and information that some people are allowed to view and there are some sets of data and information that some people are not allowed to view. Despite what the professional ethics of librarianshp may say, which can be debated forever and a day, this is a reality in today's world. At the same time, there are some sets of data and information that are not so much secret as they are just nobody's business but your own. For these reasons, methods can be put in place for restricting access to parts of all of your HTTP server. In a nutshell, there are two ways to restrict access. The first is based on the client's IP address or domain name. The other is with usernames and passwords. All of the servers described previously support both of these access control methods. Here is how to implement them. |
APACHE |
As you may expect, restricting access to your Apache server is more complicated when compared to the desktop servers. The simplest and most direct way to restrict access requires you to create IP and domain name restrictions
Below is a simple sample
# this is an .htaccess file for IP addresses # limit the types of access <Limit GET POST> # define how restriction will be processed order deny,allow # define who to deny and allow deny from all allow from .ncsu.edu # close the directive </Limit> Usernames and passwords
Restricting access based on usernames and passwords first requires you to define users and sets of users called groups. Then you create
If it hasn't been done before, you will have to compile the
For the
Next, using
where:
After this, you have to create groups. Groups are ASCII text files with the following form: group: member member memberwhere:
Now you are finally ready to create your
Here is a example
# this is an .htaccess file for passwords # define the realm AuthName The Super Secret Space # define the authentication type AuthType Basic # where are the password and group file AuthUserFile /usr/local/users/Eric/apache/conf/passwd AuthGroupFile /usr/local/users/Eric/apache/conf/group # limit the types of access <Limit GET POST> # say exactly who can access require group users # close the directive </Limit>
Once this sort of |
QUID PRO QUO |
IP and domain name restrictions Using Quid Pro Quo, restrictions based on IP addresses or domain names are called Allow/Deny. This server only permits you to "allow or deny" sets of IP address or domain names for your entire server, not parts of it. It is unfortunately an all or nothing deal. To set up this sort of restriction, select Server Settings... from the Control menu. Then select Allow/Deny from the resulting Configure Quid Pro Quo dialog box. Next you will want to add a new item and enter either IP addresses or domain names. Like the other servers, you do not have to specify the entire address or name, just enough to make it meaningful. Your configuration takes place as soon as you close the configuration dialog box. Usernames and passwords Restrictions to parts of your server using usernames and passwords are called realms. This method is more secure than the first method. Implementing it is a two step process. First, using the Configure dialog box, select Realms. Now you can enter any name you want for a realm and then a string of characters that will be used to match parts of client requests. Any URL containing the string of characters will be restricted by usernames and passwords. The second step is to choose Passwords from the Configuration dialog box. From here you can create new user names and passwords, and then associate them with realms created in the first step. Like IP/domain name restrictions, these configurations take place as soon as you close the Configuration dialog box. |
WEBSITE |
Like Quid Pro Quo, WebSite provides the means of access control through a series of dialog boxes. Its features are more robust than Quid Pro Quo's and at least on par with Apache's. Its only technical drawback is it inability to edit settings once they have been created. Many times, to make changes you must delete the old settings and recreate them with your new edits. IP and domain name restrictions The first step to limiting access by IP addresses and domain names is to open the WebSite Server Properties window and select Users. Next, create an authentication realm by clicking the New... button. Any label for your realm will do, just make it meaningful to yourself. Third, select Access Control and create a new URL Path. Enter the full path from your server's root to the directory you want to restrict. Select a realm too. Finally, specify what IP addresses and/or domain names will be allowed access to your realm using the Class Restrictions panel. If you want to restrict access to particular hosts, then select the Deny, then Allow button and enter the IP addresses or domain names you are allowing access. Conversely, if you want to deny access to particular hosts (people who might be malicious for example), then select the Allow, then Deny button and enter the hosts to deny. Close the WebSite Server Properties window and when you hear a system beep you will know the configuration has taken place. Usernames and passwords To limit access to some or all of your site, begin again with the WebSite Server Propertites window and the Users section. This time select or create a new Authentication Realm and create a new user using the New... button of the User panel. Second, go to the Access Control section and select or create a new URL Path for password protection. Remember to specify the full path name of the password protected directory begining with the root of your WebSite server. Finally, select the users allowed to access the directory by using the Add... button of the Authorized Users and Groups panel. Using the Add... button shoul result in a list of users you previously created. Again, changes won't take effect until you close the WebSite Server Properties window and you hear the system beep. |
Version: 1.5
Last updated: 2004/12/23. See the release notes.
Author: Eric Lease Morgan (eric_morgan@infomotions.com)
URL: http://infomotions.com/musings/waves/