Securing Your Web Pages with Apache Page 3

the resource being protected is “any file named foo.bar”,
in the /home/johnson/public_html directory or anywhere
underneath it. Likewise, the identification of which credentials
are authorised to access foo.bar is stated
by the directives — in this case, any user with valid credentials
in the /home/johnson/foo.htpasswd file can access it.

Realms: Areas of Controlled Access

In terms of discretionary control mechanisms on the Web, each
protected area, whether it be a single document or an entire
server, is called a realm. When a server challenges
a client for credentials, it provides the name of the realm so
the client can figure out which credentials to send.

The name of a realm is specified in the Apache configuration files
with the AuthName directive, which takes a single
argument: the name of the realm.

Note: In older versions of Apache, the entire remainder of
the line following the “AuthName” keyword was
taken to be the realm name. This caused problems when someone embedded
a quotation mark (“) in the string, since in the actual HTTP
protocol the realm name is quoted. So more recent versions of
Apache accept only a single argument to the directive; if you want
to use multiple words, like “This is my realm”, you
need to enclose the entire string within quotation marks so that
it will look like a single ‘word.’

Realm names are implicitly qualified by the URI to which they apply,
and subordinate URIs are implicitly part of the same realm. This
means that if URL:http://foo.com/a/> is in realm
“Augh”, then URL:http://foo.com/a/b/c/foo.html>
is also in realm “Augh” unless it’s been overridden.

The implicit qualification also means that even if
URL:http://foo.com/a/foo.html>
and URL:http://foo.com/b/foo.html> are declared in
two separate statements as being in realm “Foo”, they’re actually
two different realms named “Foo”. The only way they’d
both be in the same “Foo” realm is if they had a common
ancestor that was (such as URL:http://foo.com/>).

The qualification rules will cause the client to prompt for
credentials whenever it requests a document in a realm it
hasn’t visited before — even if it’s visited a different
realm with the same name.

There is no default for the AuthName directive,
except what might be inherited from an upper-level directory.

The Client/Server Authentication Handshake

When a client first attempts to access a document that’s under some
sort of discretionary access control, a lot goes on behind the scenes that
the end-user probably never sees. Since on the first attempt
the client won’t know that the resource is protected, it won’t
include any credentials. When the server receives the
request, it will go through all the phases
of access checking; when the credentials (none) don’t match
any that are valid for the resource, the server will return
a ‘not authorised’ status.