You are looking at the documentation for the 1.3 version of the Apache HTTP Server, which is no longer maintained, and has been declared "end of life". If you are in fact still using the 1.3 version, please consider upgrading. The current version of the server is 2.4.
$Revision: 1.99 $ ($Date: 2010/12/10 10:13:45 $)
Please note that this document refers to a version of the product which has been deprecated, and declared "end of life", in favor of the more recent version of the server. Information obtained here is likely to be outdated and inaccurate.
The latest version of this FAQ is available on the HTTP Server Wiki, at <http://httpd.apache.org/docs/1.3/misc/FAQ.html>. This version is no longer maintained, and contains inaccurate and grossly outdated information.
Two of the most common causes of this are:
This will cause Apache to be very paranoid about making sure a particular host address is really assigned to the name it claims to be. Note that this can incur a significant performance penalty, however, because of all the name resolution requests being sent to a nameserver.
There are several ways to do this; some of the more popular ones are to use the mod_auth, mod_auth_db, or mod_auth_dbm modules.
For an explanation on how to implement these restrictions, see Apache Week's articles on Using User Authentication or DBM User Authentication, or see the authentication tutorial in the Apache documentation.
Use the Satisfy
directive, in particular the
directive, to require that only one of the access
restrictions be met. For example, adding the following
configuration to a .htaccess or server
configuration file would restrict access to people who
either are accessing the site from a host under domain.com
or who can supply a valid username and password:
Deny from all
Allow from .domain.com
AuthName "special directory"
See the user authentication question and the mod_access module for details on how the above directives work.
Under normal circumstances, the Apache access control modules will pass unrecognized user IDs on to the next access control module in line. Only if the user ID is recognized and the password is validated (or not) will it give the usual success or "authentication failed" messages.
However, if the last access module in line 'declines' the validation request (because it has never heard of the user ID or because it is not configured), the http_request handler will give one of the following, confusing, errors:
This does not mean that you have to add an 'AuthUserFile /dev/null' line as some magazines suggest!
The solution is to ensure that at least the last module is authoritative and CONFIGURED. By default, mod_auth is authoritative and will give an OK/Denied, but only if it is configured with the proper AuthUserFile. Likewise, if a valid group is required. (Remember that the modules are processed in the reverse order from that in which they appear in your compile-time Configuration file.)
A typical situation for this error is when you are using the mod_auth_dbm, mod_auth_msql, mod_auth_mysql, mod_auth_anon or mod_auth_cookie modules on their own. These are by default not authoritative, and this will pass the buck on to the (non-existent) next authentication module when the user ID is not in their respective database. Just add the appropriate 'XXXAuthoritative yes' line to the configuration.
In general it is a good idea (though not terribly efficient) to have the file-based mod_auth a module of last resort. This allows you to access the web server with a few special passwords even if the databases are down or corrupted. This does cost a file open/seek/close for each request in a protected area.
Some organizations feel very strongly about keeping the authentication information on a different machine than the webserver. With the mod_auth_msql, mod_auth_mysql, and other SQL modules connecting to (R)DBMses this is quite possible. Just configure an explicit host to contact.
Be aware that with mSQL and Oracle, opening and closing these database connections is very expensive and time consuming. You might want to look at the code in the auth_* modules and play with the compile time flags to alleviate this somewhat, if your RDBMS licences allow for it.
You have probably configured the Host by specifying a FQHN, and thus the libmsql will use a full blown TCP/IP socket to talk to the database, rather than a fast internal device. The libmsql, the mSQL FAQ, and the mod_auth_msql documentation warn you about this. If you have to use different hosts, check out the mod_auth_msql code for some compile time flags which might - or might not - suit you.
Yes, you can - but it's a very bad idea. Here are some of the reasons:
If you still want to do this in light of the above disadvantages, the method is left as an exercise for the reader. It'll void your Apache warranty, though, and you'll lose all accumulated UNIX guru points.
If the hostname under which you are accessing the server
is different than the hostname specified in the
directive, then depending on the setting of the
directive, Apache will redirect you to a new hostname when
constructing self-referential URLs. This happens, for
example, in the case where you request a directory without
including the trailing slash.
When this happens, Apache will ask for authentication once under the original hostname, perform the redirect, and then ask again under the new hostname. For security reasons, the browser must prompt again for the password when the host name changes.
To eliminate this problem you should
ServerNameto match the name you are using in the URL; and/or
The goal here is to prevent people from inlining your images directly from their web site, but accessing them only if they appear inline in your pages.
This can be accomplished with a combination of SetEnvIf and the Deny and Allow directives. However, it is important to understand that any access restriction based on the REFERER header is intrinsically problematic due to the fact that browsers can send an incorrect REFERER, either because they want to circumvent your restriction or simply because they don't send the right thing (or anything at all).
The following configuration will produce the desired effect if the browser passes correct REFERER headers.
SetEnvIf REFERER "www\.mydomain\.com" linked_from_here SetEnvIf REFERER "^$" linked_from_here <Directory /www/images> Order deny,allow Deny from all Allow from env=linked_from_here </Directory>
Further examples can be found in the Environment Variables documentation.