Description: Cherokee is a flexible, very fast, lightweight Web server. It is implemented entirely in C, and has no dependencies beyond a standard C library. It is embeddable and extensible with plug-ins. It supports on-the-fly configuration by reading files or strings, TLS/SSL (via GNUTLS or OpenSSL), virtual hosts, authentication, cache friendly features, PHP, custom error management, and much more.
Keywords: cherokee web server httpd http

## Index → Modules

## Modules: Validators

Validator modules are used to implement an authentication mechanism. Those can be selected from the `Security` section of each rule you have in your `virtual servers`.

Note this is not the `Security` section of your virtual domains. It is the `Security` tab within each of the rules in your `Virtual server`. Those are accessible from the `Behavior` section of every configured virtual server.

Depending on the complexity of the mechanism you will have to provide more or less information.

You will always have to provide a Realm, which is a name to associate with the authenticated resource. You will also have permanently the option to provide a list of allowed users, regardless of the validator chosen.

It is important to take into consideration that there are two different authentication mechanisms:

- Basic

- Digest

Some can only handle one of those mechanisms because of technical limitations. In case the module supports both of them, the interface allows to choose whether one or both are to be used.

Here is an interface example from a simple validator:

Refer to the Authentication recipe in the Cookbook for more detailed examples.

This is the list of validator modules provided by Cherokee:

- htdigest

- htpasswd

- LDAP

- MySQL

- PAM

- Plain

- Fixed list

When you set up an authentication mechanism you must remember this: define a rule, configure its security section, adjust the priority of this rule, and last, do not flag the rule as `Final` unless you are sure you don’t want your request to match other rules.

A frequent mistake is to define a rule for authenticated resources with no configured handler, mark it as `Final` and set it on top of the priority list. This might prompt for authentication, but being a `Final` rule will always deliver a failure because no handler copes with the request.