Controlling access to your server

ou can control who accesses the files on your web site. This chapter discusses the various methods you can use to determine who has access to what files or directories on your web site. If you want to control who can configure the web server itself and who can access the server configuration files, see Managing Netscape Servers. You should also ensure the security of your web server's computer, as discussed in Chapter 8, "Using encryption and SSL."

What is access control?

Access control lets you determine who can access the server. You can use two attributes for controlling access:

User-Group requires users to enter a username and password before accessing the server. Or, the server can use client authentication by checking an LDAP directory for a security certificate before giving access to a file or set of files on your web site.

Host-IP requires the user to view your web site from a specific computer, where the server recognizes the computer by either its hostname or its IP address.

User-Group authentication

You can require users to authenticate themselves before getting access to your web site. Authentication means that users verify their identity either by entering a username and password or by using a client certificate installed in their network browser, such as Netscape Navigator or Netscape Communicator. The first method of getting the username and password is the "Basic" method, which can be done with or without encryption. The second method of using client certificates is the "SSL" method, which must be done with encryption on.

Note

To control the amount of time that ACL user cache is valid, use the ACLCacheLifetime directive in the magnus.conf file. The default value is 120 seconds. If this value is set to 0, the cache is turned off. If you use a large number for this value, you might need to restart the Enterprise Server when you make changes to the LDAP entries. For example, if this value is set to 120 seconds, the Enterprise Server might be out-of-sync for two minutes. If your LDAP is not likely to change often, use a large number. The user cache stores mappings for user/password: user->DN, cert->user and cert->userDN.

Username and password authentication

If you require users to enter a username and password to get access to your web site, you store the list of users and groups in an LDAP database, which can be either a file stored on the web server computer or an LDAP server on a remote computer (for example, a computer running Netscape Directory Server).

When users attempt to access a file or directory that has User-Group authentication, the web browser displays a dialog box asking the user to enter a username and password. The server can get this information encrypted or not, depending on whether encryption is turned on for your server.

After entering the information, the user either sees the file or directory listing requested or a message denying access. (You can customize the access-denied message that they see.) Figure 6.1 shows the authentication window. This window shows a custom message.

Users see this window when authenticating themselves to the server.

Note

If your server doesn't use SSL encryption, the username and password that the end user types are sent unencrypted across the network. Someone could intercept the network packets and read the username and password being sent to the web server. For this reason, User-Group authentication is most effective when combined with SSL encryption or Host-IP authentication, or both.

Client certificate authentication

You can confirm users' identities with security certificates before giving the users access to your web site. You can do this in two ways:

The server can use the information in the certificate as proof of identity.

The server can verify the certificate itself provided the certificates are published in an LDAP directory.

When a request comes in and you have client authentication on, the server performs these actions in order:

When the browser sends the certificate, the server checks if the certificate is from a trusted CA. If not, the server ends the transaction.

If the certificate is from a trusted CA, the server maps the certificate to a user's entry using the certmap.conf file. (See Managing Netscape Servers for more information on setting up the certificate mapping file.)

If the certificate maps correctly, then the web server follows the ACL rule specified for that user. The rule can deny or allow the request.

New in 3.x

In version 2.0, users had to enter a username and password along with sending a certificate to the server. In 3.x, the web server looks up the entry in an LDAP directory, so the access appears seamless to the end user.

Requiring client authentication for controlling access to specific resources is different than requiring client certificates for all connections to the server. To require client certificates for the entire server, you check a box in the Encryption Preferences form. To require client authentication with access control, you use the SSL authentication method.

Users must first install a client certificate in their network browser and then optionally publish the certificate in an LDAP directory, such as Netscape Directory Server.

Host-IP authentication

You can limit access to files and directories on your web site by making them available only to people using specific computers. You specify hostnames or IP addresses for the computers that you want to allow or deny. You can use wildcard patterns to specify multiple computers or entire networks. If you want to use this feature, you must have DNS running in your network and your computer must be configured to use it.

End-user access to a file or directory using Host-IP authentication appears seamless. Users can access the files and directories immediately without entering a username or password. If the computer doesn't have access, the user will get a message denying access. (You can also customize this message.)

Note

It's possible for more than one person to have access to a particular computer. For this reason, Host-IP authentication is most effective when combined with User-Group authentication. If both methods of authentication are used, the end user will have to enter a username and password before getting access.

Access control files

When you use access control on your web server, the settings are stored in a file with the extension .acl. Access control files are stored in the directory server_root/server_typeacl where server_type is the name of the server. For example, the administration server uses the directory adminacl. Netscape Enterprise Server uses httpacl.

The main ACL file name is generated-https-server-id.acl; the temporary working file is called genwork-https-server-id.acl. If you use the Server Manager forms to restrict access, you'll have these two files. However, if you want to do more complex restrictions, you can create multiple files and reference them from the magnus.conf file. There are also a few features available only by editing the files. For example, you can restrict access to the server depending on the time of day or day of the week.

Note

You also manually create and edit .acl files if you want to customize access control. For example, you might want to use an Oracle or Informix database of users instead of an LDAP database. To do this type of customizing, you need to use the access control API to program a hook into the server's access control structure. This API is written in C. For more information on the API, see the Netscape DevEdge Online site at http://developer.netscape.com.

For more information on access control files and their syntax, see the online help.

How does access control work?

You can control access to the entire server or to parts of the server (that is, directories, files, file types). When the server evaluates an incoming request, it determines access based on a hierarchy of rules called access-control entries (ACEs), and then it uses the matching entries to determine if the request is allowed or denied. Each ACE specifies whether or not the server should continue to the next ACE in the hierarchy. The collection of ACEs is called an access-control list (ACL).When a request comes in to the server, the server looks in obj.conf for a reference to an ACL, which is then used to determine access. By default, the server has one ACL file that contains multiple ACLs.

For example, suppose someone requests the following URL:

http://www.mozilla.com/my_stuff/web/presentation.html

The server would first check access control for the entire server. If the ACL for the entire server was set to continue, the server checks to see if there is an ACL for the file type (*.html). Then, it checks for an ACL for the directory, my_stuff. If one exists, it checks the ACE and then moves on to the next directory. The server continues traversing the path either until it reaches an ACL that says not to continue or until it reaches the final ACL for the requested URL (in this case, the file presentation.html).

To set up access control for this example using the Server Manager forms, you could create an ACL for the file only or for each resource leading to the file. That is, one for the entire server, one for the my_stuff directory, one for the my_stuff/web directory, and one for the file.

The following sample ACL file illustrates one way to control access to this resource.

# File automatically written

#

# You may edit this file by hand

#

version 3.0;

# This ACL allows everyone in the local database or LDAP directory

acl "agents";

authenticate (user,group) {

        prompt = "Enterprise Server";

};

deny (all) 

    user = "anyone";

allow absolute (all) 

    user = "all";

# This ACL denies all access to the my_stuff directory

acl "path=C:\Netscape\SuiteSpot\docs\my_stuff";

deny (all) 

    user = "anyone";

# This ACL allows access to anyone in the user database

acl "path=C:\Netscape\SuiteSpot\docs\my_stuff\web";

allow (all) 

    user = "anyone";

# This ACL allows access to the file to anyone in the "my_group" group

acl "path=C:\Netscape\SuiteSpot\docs\my_stuff\web\presentation.html";

allow (all) 

    user = "anyone";

    group = "my_group"

# This is the default ACL and denies access to anyone

acl "default";

deny (all)

Restricting access

This section takes you through the process of restricting access to documents on your web site. The sections following this one describe in detail each option available when using access control. Keep in mind that most access-control rules use only a subset of the available options.

There is also a section of examples you can review on page 106.

To create an access-control rule:

Go to the Server Manager and choose System Preferences|Restrict Access. A form appears where you select and edit an existing access-control rule or specify a new rule by either choosing the resource you want to apply to the rule (that is, the file, directory, or wildcard pattern you want to control) or typing a name to assign to the ACL. There are three sections to this main form:

Pick a resource lets you specify a wildcard pattern for files or directories to restrict access to (such as *.html), or you can choose a directory or a filename to restrict. You can also browse for a file or directory by using the Browse button.
Pick an existing ACL is a drop-down list of all the ACLs you've created.
Type in the ACL name is a field you can use to create named ACLs. Use this option only if you're familiar with ACL files and the obj.conf configuration file--you'll need to manually edit obj.conf if you want to apply named ACLs to resources.

The Restrict Access form has three sections.

Specify the part of your web site (the resource) that you want to control. For example, you can select Entire Server to set up access control for your entire server.


Resource wildcard	What it means
default	A named ACL created during installation that restricts write access, so only users in the local database or LDAP directory can publish documents (for example, by using the web publisher).
Entire Server	One set of rules determines the access to your entire web site, including any virtual servers you have running. To restrict access to a virtual server, specify the path of its document root.
*.html	Controls access to all files with the `.html` extension
*.cgi	Controls access to all files with the `.cgi` extension
usr/ns-home/cgi-bin/*	Controls access to all files and directories in the cgi-bin directory. Note that the path is absolute. On NT, the path must include the drive letter.
agents	A named ACL that restricts access to all agents. The web server contains this ACL by default
uri="/sales"	Controls access to the `sales` directory in the document root. To specify URIs, create a named ACL.

Click the Edit Access Control button. The right frame divides into two frames that you use to set the access control rules. If the resource you chose already has access control, the rules will appear in the top frame. The following figure briefly describes the form elements.

The ACL form contains links that, when clicked, display another form in the bottom frame (not shown).

Click the New Line button. This adds a default ACL rule to the bottom row of the table. You can use the up and down arrows in the left column to move the rule, if needed.

Select the action you want to apply to the rule by clicking the Deny link. The bottom frame displays a form where you can check if you want to deny or allow access to the users, groups, or hosts you'll specify in the following steps. Check the option you want, and then click Update.

Specify User-Group authentication by clicking the "anyone" link listed under the Users/Groups column. The bottom frame displays a form for configuring User-Group authentication. By default, there is no authentication, meaning anyone can access the resource. Check the options you want, and then click Update.

Specify the computers you want to include in the rule by clicking the "anyplace" link. The bottom frame displays a form where you can enter wildcard patterns of host names or IP addresses to allow or deny. Check the options you want, and then click Update.

Specify the access rights you want to include in the rule by clicking the "all" link. Check the access rights in the bottom frame, and then click Update.

If you are familiar with ACL files, you can enter a customized ACL entry by clicking X under the Extra column. This area is useful if you use the access control API to customize ACLs.

Check Continue if you want the access-control rule to continue in a chain. This means the next line is evaluated before the server determines if the user is allowed access. When creating multiple lines in an access-control entry, it's best to work from the most general restrictions to the most specific ones.

Repeat steps 4 through 10 for each rule you need. If you want the user to be redirected to another URL if their request is denied, check "Response when denied." Click the link to specify the URL for redirection.

Click the Submit button to store the new access-control rules in the ACL file. If you click Revert, the server removes any changes you made to the rules from the time you first opened the two-frame window. Be cautious when using Revert because you can't restore your edits. In most cases, it's probably better to delete the rule lines individually.

The following sections describe the options that appear in the bottom frame of the access-control window.

Setting access-control actions

You can specify the action the server takes when a request matches the access-control rule.

Allow means the people or computers can access the requested resource.

Deny means the people or computers cannot access the resource.

The server goes through the list of ACEs to determine what the access is. For example, the first ACE is usually to deny everyone. If the first ACE is set to "continue," the server checks the second ACE in the list. (If continue is not checked, everyone would be denied access to the resource.) If the second entry matches, then the next ACE is used. The server continues down the list until it reaches either an ACE that doesn't match or that matches but is set to not continue. The last ACE that matches is used to determine if access is allowed or denied. For example, in Figure 6.4 any user in the database can view a file (read access), but they must be in the "pubs" group if they want to publish a file to the server.

You can combine Deny and Allow statements in an ACL.

Specifying users and groups

You can restrict access to your web site based on the user who requests a resource. With user and group authentication, users are prompted to enter a username and password before they can access the resource specified in the access-control rule.

The web server uses a list of users, who might be sorted into groups, to determine access rights for the user requesting a resource. The list of users (and the groups they are included in) are stored either in a database on the web server computer or in an LDAP server, such as Netscape Directory Server. You should make sure the database has users and groups in it before you set access control.

You can allow or deny access to everyone in the database, or you can allow or deny specific people by using wildcard patterns or lists of users or groups.

To configure access control with users and groups, follow the general directions for restricting access. When you click the Users/Groups field, a form appears in the bottom frame. The following list describes the options in the form.

Anyone (No Authentication) is the default and means anyone can access the resource without having to enter a username or password. However, the user might be denied access based on other settings, such as host name or IP address.

Authenticated people only means all users requesting the resource will have to enter a username and password before getting access. If the username they enter isn't in the database, the access-control rule won't apply to them. However, if the rule says deny and then a group is listed, that group is denied, but everyone else in the database could be allowed depending on if there is another ACL that matches their request.

All in the authentication database matches any user who has an entry in the database. To use this option, you must also check "Authenticated people only."

Only the following people lets you specify certain users and groups to match. You can list the users and groups of users individually by separating the entries with commas. Or, you can enter a wildcard pattern. To use this option, you must also check "Authenticated people only."

Group matches all users in the groups you specify.
User matches the individual users you specify.

Prompt for authentication lets you specify message text that appears in the authentication window. You can use this text to describe what the user needs to enter. Depending on the operating system, the user will see about the first 40 characters of the prompt. Netscape Navigator and Netscape Communicator cache the username and password and associate them with the prompt text. This means that if the user accesses areas (files and directories) of the server that have the same prompt, the user won't have to retype usernames and passwords. Conversely, if you want to force users to reauthenticate for various areas, you simply need to change the prompt for the ACL on that resource.

Authentication Methods specifies the method the server uses when getting authentication information from the client.

Default uses the default method you specify in the obj.conf file, or "Basic" if there is no setting in obj.conf. If you check Default in this form, the ACL rule doesn't specify a method in the ACL file. Default is the best choice because you can easily change the methods for all ACLs by editing one line in the obj.conf file.
Basic uses the HTTP method to get authentication information from the client. The username and password are only encrypted if encryption is turned on for the server.
SSL uses the client certificate to authenticate the user. If you use this method, SSL must be turned on for the server. If you have encryption on, you can combine Basic and SSL methods.
Other uses a custom method you create using the access control API.

Authentication Database lets you select a database that the server uses to authenticate users. The default setting means the server looks for users and groups in either the local database or an LDAP directory, depending on the setting specified in the administration server. However, you can configure individual ACLs to use different databases. You can specify different databases and LDAP directories in the file server_root/userdb/dbswitch.conf. Then, you can choose the database you want to use in the ACL by selecting it in the drop-down list. If you use the access-control API to use a custom database (for example, to use an Oracle or Informix database), you can type the name of the database in the "Other" field in the User/Group form.

Specifying host names and IP addresses

You can restrict access to your web site based on which computer the request comes from. You specify this restriction by using wildcard patterns that match the computers' host names or IP addresses. For example, to allow or deny all computers in a specific domain, you would enter a wildcard pattern that matches all hosts from that domain, such as *.netscape.com.

To specify users from hostnames or IP addresses, follow the general directions for restricting access. When you click the From Host field (the link called "anyplace"), a form appears in the bottom frame. Check the "Only from" option and then type either a wildcard pattern or a comma-separated list of hostnames and 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. Restricting by IP address, however, is more reliable--if a DNS lookup fails for a connected client, hostname restriction cannot be used.

The hostname and IP addresses should be specified with a wildcard pattern or a comma-separated list. The wildcard notations you can use are specialized; you can only use 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 must be the right-most character. For example, 198.* is acceptable, but 198.*.251.30 is not.

For hostnames, the * must also replace an entire component of the name. That is, *.netscape.com is acceptable, but *sers.netscape.com is not. When the * appears in a hostname, it must be the left-most character. For example, *.netscape.com is acceptable, but users.*.com is not.

Setting access rights

You can set access rights to files and directories on your web site. That is, in addition to allowing or denying all access rights, you can specify a rule that allows or denies partial access rights. For example, you can give people read-only access rights to your files, so they can view the information but not change the files. This is particularly useful when you use the web publishing feature to publish documents.

When you create an access-control rule, the default access rights are set to all access rights. To change access rights, click the Rights link in the top frame, and then check or uncheck the access rights you want to set for a particular rule. The following list describes each access right you can check.

Read access lets a user view a file. This access right includes the HTTP methods GET, HEAD, POST, and INDEX.

Write access lets a user change a file or directory. Write access right includes the HTTP methods PUT, DELETE, MKDIR, RMDIR, and MOVE. To delete a file, a user must have both write and delete privileges.

Execute access applies to server-side applications, such as CGI programs, Java applets, and agents.

Delete access means that a user who also has write privileges can delete a file or directory.

List access means the user can get directory information. That is, they can get a list of the files in that directory. This applies to Web Publisher and to directories that don't contain an index.html file.

Info access means the user can get headers (HTTP HEAD method). This is mainly used by the Web Publisher.

Writing customized expressions

You can enter custom expressions for an ACL. You can use this feature if you are familiar with the syntax and structure of ACL files. There are a few features available only by editing the ACL file or creating custom expressions. For example, you can restrict access to your server depending on the time of day, day of the week, or both.

The following customized expression shows how you could restrict access by time of day and day of the week. This example assumes you have two groups in your LDAP directory: the "regular" group gets access Monday through Friday, 8:00am to 5:00pm. The "critical" group gets access all the time.

allow (read)

{

        (group=regular and dayofweek="mon,tue,wed,thu,fri");

        (group=regular and (timeofday>=0800 and timeofday<=1700));

        (group=critical)

}

For more information on valid syntax and ACL files, see the online help.

When "Access control on" is checked

When you uncheck the option labeled "Access control on," you'll get a prompt asking if you want to erase records in the ACL. When you click OK, the server deletes the ACL entry for that resource from the ACL file.

If you want to deactivate an ACL, you can comment out the ACL lines in the file generated-https-server-id.acl by putting # signs at the beginning of each line.

Responding when access is denied

You can choose the response a user sees when denied access. You can vary the message for each access-control object. By default, the user is sent a message that says the file wasn't found (the HTTP error code 404 Not Found is also sent).

To change what message is sent for a particular ACL:

In the ACL form, click the link called "Response when denied."

In the lower frame, check the radio button called "Respond with the following file."

In the text field, type a URL or URI to a text or HTML file in your server's document root that you want to send to users when they are denied access. Make sure the file doesn't contain references to other files (such as style sheets) or images because they won't be sent. Click Update.

Note

Make sure any users who get the response file have access to that file. That is, if you have access control on the response file and the user is denied access to both the original resource and the response file, the server will send the default denied response.

Make sure you submit the access -control rule by clicking the Submit button in the top frame.

Examples

This section describes some common examples for restricting access to a web server and its contents. Some of these examples assume you set up the "default" ACL to deny anyone access to the server. You can also add a "deny all" line as the first rule to each of these examples, as done in the example for the entire server.

Restricting access to the entire server

This example allows access to users in a group called "employees" who access the server from computers in a subdomain. There are no access-control rules for other resources on the server. You might use this example if you have a server for a department and you only want users to access the server from computers in a specific subdomain of your network.

To restrict access to the entire server:

In the Server Manager, choose Server Preferences|Restrict Access.

In the section called Pick a Resource, select "The entire server" from the Editing drop-down list. Click Edit Access Control. The two-frame forms appear.

Click New Line. The default rule appears, which denies all access to the server. Typically, you should deny all access to your server, and then allow specific access to users, groups, and computers; however, you might change this if you want to deny access only to a small group of users or groups. Click New Line again to create a second rule.

Click the Deny link in the second rule. In the bottom form that appears, check Allow, and then click Update.

Click the "anyone" link in the second rule. In the bottom form, type the group you want to have access to the server. For this example, type employees in the Group field. Note that the two options called "Authenticated people only" and "Only the following people" are checked automatically. Click Update.

Click the "anyplace" link in the second rule. In the bottom form, type a wildcard pattern for the host names of the computers you want to allow. For example, type *.emp.mozilla.com in the Host Names field. Click Update.

Uncheck the Continue box in the second rule of the top frame, and then click Submit. The form should look like the one in Figure 6.5. Save and apply your changes.

Restricting access to the entire server

Be sure to restart the server for the changes to take effect. The following text is the ACL file for this example.

# File automatically written

#

# You may edit this file by hand

#

version 3.0;

acl "default";

deny (all) 

    user = "anyone";

allow absolute (all) 

    user = "employees" and

    dns = "*.emp.mozilla.com";

Restricting access to a directory (path)

This example lets users in a group called "executives" have read access to a directory and its subdirectories and files on the server. The user called "ceo" has full permissions to the directory.

You might use this example if you have a directory on your server that one person owns (that is, they publish to this directory) and you want one group of users to read the files. For example, you might have a project owner who publishes status information for the project team to review.

To restrict access to a directory on the server:

In the Server Manager, choose Server Preferences|Restrict Access.

In the section called Pick a Resource, click the Browse button. In the form that appears, click the link for the directory you want to restrict. The directories listed in this form are in the servers document root. Once you click a link, the Editing drop-down list displays the absolute path to the directory.

Note

If you want to view all files in your server root, click the Options button and check the box labeled "List files as well as directories" and then click OK.

Click Edit Access Control. The two-frame forms appear.

Click New Line twice to create two rules. Don't edit the default values for the first rule--they deny all access to the directory. You'll edit the second rule to allow read access to the "executives" group.

Click the Deny link in the second rule. In the bottom form that appears, check Allow, and then click Update.

Click the "anyone" link in the second rule. In the bottom form, type the group you want to have access to the server. For this example, type executives in the Group field. Click Update.

Click the "all" link in the top frame. Uncheck the Write and Delete access rights. This means the users in the executives group can't add or remove files, but they can view them and run any applications in the directories. Click Update.

Click New Line to create a rule for the "ceo" user. Check Allow for the third rule, as you did in Step 5.

Click the "anyone" link. In the bottom form, type ceo in the User field. Click Update.

Uncheck Continue for both the second and the third rules. This means that the server ignores any ACLs for directories or files under the directory you specified in Step 2. The form should look like the one in Figure 6.6. Click Submit, and then save and apply your changes.

Restricting access to a path in the server

The entry in the generated.https-serverid.acl file for this example looks like this:

acl "path=d:/netscape/suitespot/docs/senior-staff/";

deny (all) 

    user = "anyone";

allow absolute (read,execute,list,info) 

    group = "executives";

allow absolute (all) 

    user = "ceo";

Restricting access to a URI (path)

This example uses a URI to control access to a single user's content on the web server. URIs are paths and files relative to the server's document root directory. Using URIs is an easy way to manage your server's content if you frequently rename or move all or part of it (for example, for disk space). It's also a good way to handle access control if you have additional document roots.

This example gives anyone read access to files and directories in the path specified by the URI /my_directory. Only one user ("me" in this example) has full access to the directories and files.

You might use this example if you have several users who publish their content on your server. The users want to have write access to their content, and they want anyone to have read/execute access.

To restrict access to a URI:

In the Server Manager, choose Server Preferences|Restrict Access.

In the section called "Type in the ACL name," type the URI you want to control. For example, type uri=/my_directory. Click Edit Access Control. The two-frame forms appear.

Click New Line to create the first rule that allows all users read access.

Click the Deny link. In the bottom form that appears, check Allow, and then click Update.

Click the "all" link in the top frame. Uncheck the Write and Delete access rights. This means users can't add or remove files, but they can view them and run any applications in the directories. Click Update.

Click New Line to create a rule for the owner of the directory. Check Allow for the second rule.

Click the "anyone" link. In the bottom form, type me in the User field. Click Update.

Uncheck Continue for both the first and second rules. This means that the server ignores any ACLs for other URIs, directories, or files under the URI you specified in Step 2. The form should look like the one in Figure 6.7. Click Submit, and then save and apply your changes.

Restricting access to a URI (path) in the document root

The entry in the generated.https-serverid.acl file for this example looks like this:

acl "uri=/my_directory";

allow absolute (read,execute,list,info) 

    user = "anyone";

allow absolute (all) 

    user = "me";

Restricting access to a file type

This example controls write and delete access to all files with the extension .cgi. You might use this example if you only want specific users to create programs that run on your server. In this example, anyone can run the programs, but only users in the "programmers" group can create or delete them.

To restrict access to a file type:

In the Server Manager, choose Server Preferences|Restrict Access.

In the section called "Pick a resource," click the Wildcard button. In the prompt that appears, type *.cgi and click OK. This wildcard pattern matches any request that contains a file or directory with the .cgi extension.

Click Edit Access Control. The two-frame forms appear.

Click New Line to create the first rule that will allow all users read access.

Click the Deny link. In the bottom form that appears, check Allow, and then click Update.

Click the "all" link in the top frame. Uncheck the Write and Delete access rights. This means users can't add or remove files or directories with the .cgi extension. Click Update.

Click New Line to create a rule that allows write and delete access to the "programmers" group. Check Allow for the second rule, like you did in Step 5.

Click the "anyone" link. In the bottom form, type programmers in the Group field. Click Update. The form should look like the one in Figure 6.8. Click Submit and then save and apply your changes.

Restricting access to a file type--in this case, to files with the .cgi extension

In this example, both continue boxes are checked. This means that if a request for a file comes in, the server will first look at the ACL for the file type, and then it will continue to look for another ACL that matches (for example, am ACL on the URI or the path). The server checks ACLs in this order:

Pathcheck functions in obj.conf. For example, these could be wildcard patterns for files or directories. The entry in the ACL file would appear as follows: acl "*.cgi";

URIs. For example, a path relative to the document root. The entry in the ACL file would appear as follows: acl "uri=/my_directory";

pathnames. For example, an absolute path to a file or directory. The entry in the ACL file would appear as follows: acl "path=d:\netscape\suitespot\docroot1\sales/";

The entry in the generated.https-serverid.acl file for this example looks like this:

acl "*.cgi";

allow (read,execute,list,info) 

    user = "anyone";

allow (all) 

    group = "programmers";

Restricting access based on time of day

This example restricts write and delete access to the server during working hours. You might use this example if you don't want people publishing documents at times when people might be accessing the files. This example allows users to publish during the evening during the week (between 6:00pm and 6:00am, Monday through Friday) and all time during the weekend.

To restrict access based on time of the day and day of the week:

In the Server Manager, choose Server Preferences|Restrict Access. In the section called Pick a Resource, select "The entire server" from the Editing drop-down list. (You can select any resource.) Click Edit Access Control. The two-frame forms appear.

Click New Line.

Click the Deny link. In the bottom form that appears, check Allow, and then click Update.

Click the "all" link in the top frame. Uncheck the Write and Delete access rights. This means that if a user wants to add, update, or delete a file or directory, this rule won't apply and the server will search for another rule that matches. Click Update.

Click New Line to create a rule that restricts the write and delete methods. Check Allow for the second rule.

Click the X link to create a customized expression. In the bottom form, edit the existing lines to include the following:

user = "anyone" and

dayofweek = "sat,sun" or

(timeofday >= 1800 and

timeofday <= 600)

Click Submit. If you made any errors in the custom expression, you'll get a JavaScript alert. Correct any changes and click Submit again.

Restart your server for the changes to take effect.

Converting a 2.0 ACL file

If you have a 2.0 server installed when you install the 3.0 server, you'll have the option of converting your 2.0 ACL file to a 3.0 format. You can also convert them after installation. For example, if you have the access-control files on a different computer, you can copy them to the 3.0 server computer and then convert them.

To convert 2.0 ACL files:

Choose System Settings|Convert 2.0 ACL File.

By default, the server assumes you copied the 2.0 file to the directory server_root/httpacl and named the file generated.https-serverid.acl. If you have copied and renamed the file, check the Default radio button and then click OK. If you haven't copied and renamed the file, follow the rest of these steps.

Type the absolute path to the 2.0 access control file.

Type a file name you want to assign to the 3.0 file. If you don't specify a 3.0 file name, the 2.0 file is converted and saved with the default name generated.https-serverid.acl.

Warning

If you don't specify a 3.0 path and filename, the conversion will overwrite the default 3.0 file if one exists.

Click OK.

If your 2.0 ACL files contain references to databases, convert the database entries to the 3.0 local database or LDAP directory. You might need to edit the userdb/dbswitch.conf file to reference the database files.

Restart the web server. (From the Server Manager, choose Server Preferences|On/Off, and then click Server On to restart the web server.)

Once the file is converted, you can manually edit it. Or if you converted to the default file generated.https-serverid.acl, you can use the Server Manager forms to edit the settings.