Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

59 lines (44 sloc) 2.301 kb
== link:index.html[Index] -> link:modules.html[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.
.Interface sample for simple validator
image::media/images/admin_validators_pam.png[Validator PAM]
Refer to the link:cookbook_authentication.html[Authentication] recipe
in the link:cookbook.html[Cookbook] for more detailed examples.
This is the list of validator modules provided by Cherokee:
* link:modules_validators_htdigest.html[htdigest]
* link:modules_validators_htpasswd.html[htpasswd]
* link:modules_validators_ldap.html[LDAP]
* link:modules_validators_mysql.html[MySQL]
* link:modules_validators_pam.html[PAM]
* link:modules_validators_plain.html[Plain]
* link:modules_validators_authlist.html[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.
Jump to Line
Something went wrong with that request. Please try again.