Control over who gets to see certain information or use a certain service can be achieved in three ways; RXML, security patterns or .htaccess files. All three ways have one thing in common, they make use of an authentication module. The authentication module contains a user database with user names, passwords and information about the users. Challenger comes with three such modules, the User database and security module, the SQL User database module and the LDAP directory authorization module.

In RXML, access control is achieved through use of the <if> tag. It is possible to make a very fine-grained access control system with this tag, since access to information on the actual pages can be limited. See the If page in the Web Site Creator manual for more information.

Security patterns are used to limit access to an entire module. For example, it can be used to make sure only internal users can access the Demo module.

.htaccess is a standard used by many web servers and can be used to limit access to certain directories or files. It is implemented through the .htaccess support module. More information about .htaccess can be found in the security chapter in the "Web Site Creator"-manual.

Security patterns
Security Patterns are one of the variables under Builtin variables. They can be used to control who gets to access a certain module.

If security patterns are not used, anyone can access the module. Once a security pattern is entered only users who are matched by the security pattern will be granted access.

The patterns are scanned from top to bottom. Each line contains a rule with a pattern matching users who should be affected by the rule.

Rules
The rule determines what should happen in case the user or computer is matched by the pattern. Should the request be denied or granted?

accept

A user matched by an accept rule will be granted access, unless she is matched by a deny rule further down. The processing of patterns will continue, in order to determine if such a deny rule exists.

allow

A user matched by an allow rule will be granted access. No further processing of the patterns is required.

deny

A user matched by a deny rule will be denied access. No further processing of the patterns is required.

Patterns
Each rule contains one of the following patterns, that are used to match users that are to be affected by the rule:

ip=IP/bits

Grant/deny access from a network, IP specifies the network address, bits the size of the network. allow 194.52.182.0/8 will grant access to any machine who's IP-address starts with 194.52.182.

ip=IP:mask

Grant/deny access from a network, IP specifies the network address, mask the subnet mask. allow 194.52.182.0:255.255.255.0 will grant access to any computer whose IP address starts with 194.52.182.

ip=pattern

Grant/deny access from a named network. allow *.idonex.se will grant access to any computer who is named something ending with idonex.se. * is used to match zero or more letters while ? matches only one letter.

user=username

Grant/deny access to a specified user. The user will be authenticated using the authentication module or .htaccess password file. This option is usually silent, that is, a user will not be prompted for a user name and password if she fails to authenticate properly.

user=any will grant/deny access to anyone with a valid account.

Example

Will grant access to any user who is authenticated or comes from the network 194.52.182.0.

.htaccess support
Support for NCSA/Apache .htaccess files. See the security chapter in the "Web site Creator"-manual for information about how to use .htaccess files.

Cache the failures

This causes the .htaccess support module to remember where it failed to find a .htaccess file. This improves performance significantly, but users must do a reload to get a new .htaccess file to take effect.

Deny file list

Files to which access will always be denied, no matter who tries to access them. Usually .htaccess related files are protected this way to make it impossible for an external user to get any information about how the access control system works.

User database and security
This module fetches user account information from the operating system's user database. It is used when the users that should have access to the web server already have accounts on the system. This module must be used for modules enabled if the CGI scripting support module or the Pike script support module are to be able to run scripts as the user who owns the script.

Variables

Password database request method

How to get account information from the operating system. Choose one of the following options:

ypcat

Use the ypcat program. For systems that use yp.

file

Read accounts from the password file specified in the Password database file variable.

shadow

Read accounts on a system that uses shadowed password files. You need to specify a password file in the Password database file variable as well as a shadow password file in the Password database shadow file variable.

niscat

Use the niscat program. The same as ypcat for Solaris systems, where yp has been renamed nis.

getpwent

Use the system call getpwent to get user information. This will work on all systems, but is slower than the other methods.

none

Don't import any user account information. Let any username through no matter what password was submitted.