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.
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.
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 112.
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.
The following items are some common examples
of resources you might use for access control.
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 or delete a file. Write access right
includes the HTTP methods PUT, DELETE, MKDIR, RMDIR, and MOVE.
-
Execute access applies to server-side applications, such as CGI
programs, Java applets, and agents.
-
Delete access means a user 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)
You might want to select the entire text element
and copy it to memory--if there are errors, you'll have to reenter the
text. Click Update. The top form will display "Unrecognized expressions"
in the Users/Groups and From Host fields, because you created a custom
expression.
-
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.
Copyright 1997 Netscape Communications Corporation.
All rights reserved.