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.

This article was originally published on Jun 29, 2000

Thanks for your registration, follow us on our social networks to keep up-to-date