• Choose a category
• All
• Classic-Fiction

PROPFIND

PROPPATCH

MKCOL

COPY

MOVE

LOCK

UNLOCK

These methods are all defined in the WebDAV specification and provide the means for a capable client to manipulate resources on the web server, just as it would manipulate files on a local hard disk. These methods are enabled automatically when the WebDAV Apache module is enabled, and are only needed when you want to provide WebDAV functionality to your users. They should be disabled otherwise.

The directive allows access control to be performed for known request methods. It is used in the same way as the directive is to protect directories. The following example allows only authenticated users to make changes on the server using the PUT and DELETE methods:

AuthType Basic

AuthName "Content Editors Only"

AuthUserFile /usr/local/apache/conf/auth.users

Require valid-user

Since the directive only works for named request methods, it cannot be used to defend against unknown request methods. This is where the directive comes in handy. It does the opposite and only allows anonymous access to requests using the listed methods, forcing authentication for others. The following example performs essentially the equivalent functionality as the previous example but forces authentication for all methods except GET, HEAD, and POST:

AuthType Basic

AuthName "Content Editors Only"

AuthUserFile /usr/local/apache/conf/auth.users

Require valid-user

Combining authentication with network access control

Authentication-based and network-based access control can be combined with help from the Satisfy configuration directive. This directive can have two values:

Any

If more than one access control mechanism is specified in the configuration, allow access if any of them is satisfied.

All

If more than one access control mechanism is specified in the configuration, allow access only if all are satisfied. This is the default setting.

This feature is typically used to relax access control in some specific cases. For example, a frequent requirement is to allow internal users access to a resource without providing passwords, but to require authentication for requests coming in from outside the organization. This is what the following example does:

# Network access control

Order Deny,Allow

Deny from all

Allow from 192.168.254.

# Authentication

AuthType Basic

AuthName "Content Editors Only"

AuthUserFile /usr/local/apache/conf/auth.users

Require valid-user

# Allow access if either of the two

# requirements above are satisfied

Satisfy Any

Combining multiple authentication modules

Though most authentication examples only show one authentication module in use at a time, you can configure multiple modules to require authentication for the same resource. This is when the order in which the modules are loaded becomes important. The first authentication module initialized will be the first to verify the user's credentials. With the default configuration in place, the first module will also be the last. However, some (possibly all) authentication modules support an option to allow subsequent authentication modules to attempt to authenticate the user. Authentication delegation happens if the first module processing the request is unable to authenticate the user. In practice, this occurs if the user is unknown to the module. If the username used for the request is known but the password is incorrect, delegation will not happen.

Each module uses a directive with a different name for this option, but the convention is to have the names end in "Authoritative." For example, the AuthAuthoritative directive configures mod_auth, and the AuthDBMAuthoritative directive configures mod_auth_dbm.

Single Sign-on

The term single sign-on (SSO) is used today to refer