Table of Contents

  • Introduction
  • Installation
  • Handling Challenger
  • Virtual Servers
  • Configuration Examples
  • Modules
  • Filesystems
  • RXML Tags
  • Graphics
  • Proxy
  • Databases
  • Miscellaneous Modules
  • Security Considerations
    · Introduction
    · Challenger User
    · Access Control
    · Trustlevels
  • Scripting
  • Frontpage
  • Upgrading
  • Third Party Extensions
  • Portability
  • Reporting Bugs
  • Appendix
  • Access Control
    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 two such modules, the User database and security module and the SQL User database 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 acctual pages can be limited. See the If page in the User 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 htaccess chapter in the User 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 reuqest 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

    allow user=any
    allow ip=194.52.182.0/8

    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 htaccess chapter in the User 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 is submitted.