This directive tests whether an authenticated user is authorized according to a particular authorization provider and the specified restrictions. Some of the allowed syntaxes provided by mod_authz_user and mod_authz_groupfile are:

Require user userid [userid] ...

Only the named users can access the resource.

Require group group-name [group-name] ...

Only users in the named groups can access the resource.

Require valid-user

All valid users can access the resource.

Other authorization modules that implement require options include mod_authnz_ldap, mod_authz_dbm, mod_authz_dbd, mod_authz_host, and mod_authz_owner.

For a complete authentication and authorization configuration, Require must be accompanied by AuthName, AuthType and AuthBasicProvider or AuthDigestProvider directives, and directives such as AuthUserFile and AuthGroupFile (to define users and groups) in order to work correctly. Example:

Access controls which are applied in this way are effective for all methods. This is what is normally desired. If you wish to apply access controls only to specific methods, while leaving other methods unprotected, then place the Require statement into a Limit section.

When multiple Require directives are used in a single configuration section, the first one to authorize a user authorizes the entire request, and subsequent Require directives are ignored. In other words, all Require directives are enclosed in an implied MatchAny directive.

This directive is similar to the Require directive; it tests whether an authenticated user is authorized according to a particular authorization provider and the specified restrictions.

Unlike the Require directive, it may be used with and inside authorization container directives such as MatchAll.

Furthermore, its result may be negated through the use of the not option. As with other negated authorization directives, in this case the Match directive may only either fail or return a neutral result, and can therefore never independently authorize a request.

In the following example, all users in the alpha and beta groups are authorized, except for those who are also in the reject group.

When multiple Match directives are used in a single configuration section and are not contained in another authorization directive like MatchAny, they are implicitly contained within a MatchAll directive. Thus for the user to be authorized, all such Match directives must not fail, and at least one must be successful.

MatchAll and </MatchAll> are used to enclose a group of authorization directives of which none must fail and at least one must succeed in order for the MatchAll directive to succeed.

If none of the directives contained within the MatchAll directive fails, and at least one succeeds, then the MatchAll directive succeeds. If none succeed and none fail, then it returns a neutral result. In all other cases, it fails.

MatchAny and </MatchAny> are used to enclose a group of authorization directives of which one must succeed in order for the MatchAny directive to succeed.

If one or more of the directives contained within the MatchAny directive succeed, then the MatchAny directive succeeds. If none succeed and none fail, then it returns a neutral result. In all other cases, it fails.

MatchNotAll and </MatchNotAll> are used to enclose a group of authorization directives of which some must fail or none must succeed in order for the MatchNotAll directive to not fail.

If none of the directives contained within the MatchNotAll directive fail, and one or more succeed, then the MatchNotAll directive fails. In all other cases, it returns a neutral result. Thus as with the other negated authorization directives, it can never independently authorize a request because it can never return a successful result. It can be used, however, to restrict the set of users who are authorized to access a resource.

MatchNotAny and </MatchNotAny> are used to enclose a group of authorization directives of which none must succeed in order for the MatchNotAny directive to not fail.

If one or more of the directives contained within the MatchNotAny directive succeed, then the MatchNotAny directive fails. In all other cases, it returns a neutral result. Thus as with the other negated authorization directives, it can never independently authorize a request because it can never return a successful result. It can be used, however, to restrict the set of users who are authorized to access a resource.

When authorization is enabled, it is normally inherited by each subsequent configuration section, unless a different set of authorization directives are specified. This is the default action, which corresponds to an explicit setting of MergeAuthz Off.

However, there may be circumstances in which is it desirable for a configuration section's authorization to be combined with that of its predecessor while configuration sections are being merged. Two options are available for this case, MatchAll and MatchAny.

When a configuration section contains AuthzMerge MatchAll or AuthzMerge MatchAny, its authorization logic is combined with that of the nearest predecessor (according to the overall order of configuration sections) which also contains authorization logic as if the two sections were jointly contained within a MatchAll or MatchAny directive, respectively.

AuthzProviderAlias and </AuthzProviderAlias> are used to enclose a group of authorization directives that can be referenced by the alias name using the directive Require.