records and specify that only a group of people you call Personnel can see the files in that directory. When someone tries to access a restricted document, they are prompted for a name and password. If they enter a name and password that correspond to a name-password pair in your private list of people in Personnel, they are allowed to see the requested document. Otherwise, they are told they didn't enter a valid name and/or password.
If your server has SSL enabled, the user's name and password are sent encrypted. Otherwise, names and passwords are sent openly, and can be intercepted.
When changing access control on files or directories on your server, you usually follow this process: ImportantAlthough Netscape servers support multiple databases, you might need only one database for all your users. The main reason for maintaining multiple databases is if you have different servers installed on the same computer. A mail server might have a completely different database than a news server or a web server. If you're only maintaining one server on your computer, however, you'll find it's easier to keep track of your users if they're all in the same database. If you need to separate your users, use the grouping features described on page 75. (Netscape servers support multiple databases because older server programs did not have grouping capabilities.)
The server stores its databases in the directory userdb, off the root server directory. When specifying a database, use only its name, not its directory path. Using the Manage User Databases form, you can perform three tasks:
You can have any number of users in your database, and you can put them into as many groups as you like. For example, you might want to separate your users into a Personnel group and a Sales group. You can put a user into more than one group.
You can also maintain multiple databases, but it's much easier to keep track of your users if they're in one database. (Multiple databases are remnants of older server programs that did not have grouping capabilities.)
You can create users, remove them, or change their passwords. You can also list all the users in your database.
Creating a user
To import users from an existing database, see "Importing users" on page 78. To add a user manually,
d* into the Filter field. For more information on wildcard patterns,
refer to "Understanding wildcard patterns" on page 39.
To save even more time, you can also put other groups into a group. For example, your Sales and Marketing groups could both be part of the group Business. A group may belong to multiple other groups.
The members of a group must all be within the same database. It's recommended that you use only one database for all your users, since your users are easier to keep track of that way, and you can more fully exploit the power of grouping. Also, user databases are shared across all servers that are installed (web servers, mail servers, news servers, and so on.), so you may want to have a different database for each server to avoid confusion.
If you need to separate your users, use the grouping features. (Netscape servers support multiple databases because older server programs did not have grouping capabilities.)
You can create or remove groups, or edit their contents. You can also list the contents of groups.
Creating a group
To create a group,
Once you have created a group, you can add a user to it by editing that user. (See page 74.)
Note!The groups and users are not selected unless they are highlighted.
s* into the Filter field. For more information on wildcard patterns,
see "Understanding wildcard patterns" on page 39.
user1:password1
user2:password2
user3:password3To import users from an existing file,
contacts. You don't want Marketing (or anyone else) to see the files. Using your server's access control, you specify that by default, the contacts directory is not available for any kind of access to anyone. Then you specify that the Sales group is an exception to the default access. You further specify that not only can they read the files in that directory, but they can also change them. To change the access control for part of your server,
When you set these access defaults, they will apply to everyone attempting to read or write to the files or directories you specified earlier.
401 Unauthorized.
When determining the exceptions who are denied access, you can specify users from specified hostnames or IP addresses.
First you must specify how hostnames are processed. If you want to deny users from only the exact hostnames you'll specify below, click Include specified names only. However, if you also want to deny users from alias domains of your specified hostnames, click Include aliases of specified names.
To deny users from specific hostnames or IP addresses, type a comma-separated list of hostnames or IP addresses. Restricting by hostname is more flexible than by IP address--if a user's IP address changes, you won't have to update this list. But on the other hand, restricting by IP address is more reliable--if a DNS lookup fails for a connected client, hostname restriction cannot be used.
You can also use a wildcard pattern for hostnames and IP addresses. The wildcard notations you can use are specialized; you can only use the
For hostnames, the
*. Also, for the IP address, the * must replace an entire byte in the address. That is, 198.95.251.* is acceptable, but 198.95.251.3* is not. When the * appears in an IP address, it replaces all information to the right. For example, 198.* is acceptable, but 198.*.251.30 is not.* must also replace an entire part of the name. That is, *.netscape.com is acceptable, but *sers.netscape.com is not. When the * appears in a hostname, it replaces all information to the left. For example, *.netscape.com is acceptable, but users.*.com is not. Allowing access to a resource
In the Restrict Access form described on page 79, you set the default read and write access of a resource (a directory or group of files). If you set read or write access to deny all access by default, you can specify exceptions by clicking the Permissions button. The Allow Access to a Resource form appears.
When determining the exceptions who are allowed access, you can specify two types of users:
You specify both types of users in this form. With the exception of steps 3 and 4, listed below, if a user meets any of the criteria specified in this form, they are allowed to access the resource.
After this step, the server tries to match the incoming host name with any hostnames specified in this form. If the client passes, the document is served. If the client fails the test, the server then checks its IP address against the restriction IP addresses. If it passes, the document is served. If it fails, then the server sends the message specified in the Restrict Access form (see page 79).
If you will be specifying hostnames to allow users from, decide how you want the hostnames processed. If you want to allow only users from the exact hostnames you'll specify below, click Include specified names only. However, if you also want to accept users from alias domains of your specified hostnames, click Include aliases of specified names.
To allow users from specific hostnames or IP addresses, enter a wildcard pattern of hostnames or IP addresses in text fields. Restricting by hostname is more flexible than by IP address--if a user's IP address changes, you won't have to update this list. But on the other hand, restricting by IP address is more reliable--if a DNS lookup fails for a connected client, hostname restriction cannot be used.
Remember that the hostname and IP addresses should be specified with a wildcard pattern and/or a comma-separated list.
If someone is allowed access by virtue of their hostname or IP address, they are not prompted for a login name and password. All other users are asked for that information. To allow access to the users listed in your database, follow these steps.
Bob,Mary in the Users field. If you leave this entry blank, all users from the database are allowed access.