Server content is seldom managed entirely by one person. You might need to allow end users to access a subset of configuration options so that they can configure what they need to, without giving them access to the Sun Java System Web Server. The subset of configuration options is stored in dynamic configuration files.
The following topics are described in this section:
The Sun Java System Web Server supports.htaccess dynamic configuration files. You can enable .htaccess files either through the user interface or by manually changing the configuration files. The files that support the .htaccess file are in the server_root/plugins/htaccess directory. These files include a plug-in that enables you to use .htaccess files and a script for converting .nsconfig files to .htaccess files.
You can use .htaccess files in combination with the server’s standard access control. The standard access control is always applied before any .htaccess access control, regardless of the ordering of PathCheck directives. Do not require user authentication with both standard and .htaccess access control when user-group authentication is ”Basic’ You could use SSL client authentication via the standard server access control, and also require HTTP ”Basic’ authentication via an .htaccess file.
This section includes the following topics:
To configure your Sun Java System Web Server to use the .htaccess file, perform the following steps:
Access the Server Manager and select the server instance for which you want to enable .htaccess access control.
Click the Class Manager link at the top of the screen.
Select the Content Mgmt tab.
Click the .htaccess Configuration link.
Select the server to be edited:
Select Yes to activate .htaccess.
Enter the file name for which you want to add .htaccess configuration to be added.
Click OK.
When finished, click Apply.
Select Hard Start/Restart or Dynamically Apply.
To manually enable your sever to use the .htaccess, you first need to modify the server’s magnus.conf file to load, initialize, and activate the plug-in.
Access the magnus.conffile in the server_root/https-server_name/config directory.
After the other Init directives, add the following lines:
For UNIX/Linux:
Init fn=”load-modules” funcs=”htaccess-init,htaccess-find”shlib=”server_root/plugins/htaccess/htaccess.so” NativeThread=”no”Init fn=”htaccess-init”
For Windows:
Init fn=”load-modules” funcs=”htaccess-init,htaccess-find,htaccess-register”shlib=”server_root/plugins/htaccess/htaccess.dll” NativeThread=”no”Init fn=”htaccess-init”
For HP:
Initfn=”load-modules” funcs=”htaccess-init,htaccess-find,htaccess-register” shlib=”<server_root>/plugins/htaccess/htaccess.sl” NativeThread=”no”
Init fn=”htaccess-init”
(Optional) Make the final line should read:
Init fn=”htaccess-init”[groups-with-users=yes]
Click Save from the File menu.
Open obj.conf.
Add the PathCheck directive as the last directive in the object.
To activate .htaccess file processing for all directories managed by a virtual server, add the PathCheck directive to the default object in the object.conf file:
<Object name="default">
...
PathCheck fn="htaccess-find"
</Object>
.htaccess processing should be the last PathCheck directive in the object.
To activate .htaccess file processing for particular server directories, place the PathCheck directive in the corresponding definition in magnus.conf.
To name your .htaccess files something other than .htaccess, you must specify the filename in the PathCheck directive using the following format:
PathCheck fn="htaccess-find" filename="filename"
The next time you use the Administration Server, you are warned that manual edits have been applied. Click Apply to accept your changes.
Subsequent access to the server is subject to .htaccess access control in the specified directories. For example, to restrict write access to .htaccess files, create a configuration style for them, and apply access control to that configuration style. For more information, see Chapter 17, Applying Configuration Styles.
The Sun Java System Web Server 6.1 includes the htconvert plug-in for converting your existing .nsconfig files to .htaccess files. The .nsconfig files are no longer supported. If you have been using.nsconfig files, you should convert them to .htaccess files.
When activated, htconvert searches the given server.xml files for pfx2dir and document-root directives. Each .nsconfig file found is translated into an .htaccess file. Multiple obj.conf files can be converted depending on configuration.
If there is an existing .htaccess file, htconvert will produce an .htaccess.new file, and slow a warning. If .htaccess and .htaccess.new already exist, the new file will be named .htaccess.new.new. The.new is repeatedly appended.
The htconvert plug-in currently only supports the RestrictAccess and RequireAuth directives, and the <Files> wrapper. If <Files> other than <Files*> are presented, the script issues a warning and behave as though all files in the directory are to be access-controlled.
To convert your files, at the command prompt, enter the path to Perl on your system, the path to the plug-in script, and the path to your server.xml file. For example:
server_root\install\perl server_root/plugins/htaccess/htconvert server_root/https-server_name/config/server.xml
All .nsconfig files are converted to .htaccess files, but not deleted.
The groups-with-users option facilitates handling large numbers of users in groups. If you have many users in a group, follow these steps:
Revise the format of the user file format to list all the groups a user belongs to:
username:password:group1,group2,group3,...groupn
Revise the AuthGroupFile directive to point to the same file as the AuthUserFile.
Alternatively, you can:
Remove the AuthGroupFile directive entirely.
Add the following to the Init fn=htaccess-init line in the magnus.conf file:
groups-with-users="yes"
The htaccess-register function allows you to create your own authentication methods. Like Apache you can create external authentication modules and plug them into the .htaccess module via htaccess-register. Two sample modules are provided in server_root/plugins/nsapi/htaccess.
You can use external modules to create one or more new directives. For example, you might specify the user database for authentication. The directives may not appear within <Limit> or <LimitExcept> tags.
The htpasswd command is used to generate or modify a password file suitable for use with the htaccess access control mechanism.
The htpasswd usage is as follows:
htpasswd [-c] passwordfile username [password]
Where, -c creates a new passwordfile(overwriting an old one if it exists). Without -c, the command will modify the existing file by either updating the user's password (if user already exists) or adding a new user with the given name. If the optional password argument is not given, it will prompt interactively for the password to assign.
htaccess is not the preferred access control mechanism in Web Server. Wherever possible, use ACLs instead.
The following example shows an .htaccess file:
<Limit GET POST> order deny,allow deny from all allow from all </Limit> <Limit PUT DELETE> order deny,allow deny from all </Limit> AuthName mxyzptlk.kawaii.com AuthUserFile /server_root/mxyz-docs/service.pwd AuthGroupFile /server_root/mxyz-docs/service.grp
The following .htaccess directives are supported in this release:
Allows from host where:
host is all, to allow access from all client hosts
host is all or the last part of a DNS host name
host is a full or partial IP address
Does not need to be enclosed within a <Limit> or <LimitExcept> range but usually is.
Allows access to the specified hosts. Normally appears inside a <Limit> range.
Deny from host where:
host is all, to deny access from all client hosts
host is all or the last part of a DNS host name
host is a full or partial IP address
Does not need to be enclosed in a <Limit> <LimitExcept> range but usually is.
Denies access to the specified hosts. Normally appears inside a <Limit> range.
AuthGroupFile filename where filename is the name of file containing group definitions in the form: groupname: user user.
Must not appear within a <Limit> or <LimitExcept> range.
Specifies that the named group file is to be used for any group definitions referenced in a require group directive. Note that if the filename specified in an AuthGroupFile directive is the same as the filename in an AuthUserFile directive, the file is assumed to contain users and groups in the format:
username:DES-encrypted-password:comma-separated-list-of-groups
AuthUserFile filename where:
filename is the name of file containing user definitions in the form: username:password
username is a user login name, and password is the DES-encrypted password.
Must not appear within a <Limit> or <LimitExcept> range.
Specifies that the named user file is to be used for any user names referenced in a require user or require valid-user directive.
Note that the use of groups-with-users=yes in the Init fn=htaccess-init directive in obj.conf, or specifying an AuthGroupFile directive with the same filename, causes that file to be assumed to be in the format:
username:DES-encrypted-password:comma-separated-list-of-groups
AuthName authentication realm where authentication realm is a string identifying an authorization realm to be associated with any request for user authentication.
Must not appear within a <Limit> or <LimitExcept> range.
The authentication realm string typically appears in the prompt for username and password on the client side. It may affect caching of username and password on the client.
AuthType Basic. Must not appear within a <Limit> or <LimitExcept> range.
Specifies the user authentication method as HTTP Basic Authentication, the only method currently supported.
<Limit method method ...>
allow, deny, order, or require directives
</Limit>
where method is an HTTP method such as GET, POST, or PUT. Any method that the web server understands can be used here.
Applies the enclosed directives only for requests using the specified HTTP methods.
<LimitExcept method method ...> allow, deny, order, or require directives </LimitExcept>
where method is an HTTP method such as GET, POST, or PUT. Any method that the web server understands can be used here.
Applies the enclosed directives only for requests types not matching the specified HTTP methods.
Order ordering where ordering is one of:
allow, deny
deny, allow
mutual-failure
Does not need to be enclosed within a <Limit> or <LimitExcept> range, but usually is.
allows, denies, evaluates allow directives and then deny directives
denies, allows, evaluates deny directives and then allow directives
mutual-failure denies access for a host listed in both allow and deny directives, regardless of their ordering
require group groupname groupname
require user username username
require valid-user
Does not need to be enclosed within a <Limit> or <LimitExcept> range, but usually is.
require group requires the authenticated user to be a member of one of the specified groups.
require user requires the authenticated user to be one of the specified users.
require valid-user requires an authenticated user.
By default, server support for HTTP PUT is disabled. You can activate HTTP PUT using the Remote File Manipulation page of Content Mgmt in the Class Manager. Be careful when allowing PUT access to directories containing .htaccess files, since it will allow them to be replaced. PUT access can be prevented on all files in a directory by restricting access. See Restricting Access to a Directory (Path).