Security and Apache: An Essential Primer - page 3
Maxwell's Demon and Hat ColourIn 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
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.'
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/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
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 authorized phases of access checking; when the credentials (none) don't match any that are valid for the resource, the server will return a "not authorized" status.
In almost all cases, a client that receives a "not authorized" response will realize that it didn't send any credentials and will pop up a dialogue box for the end-user to complete. This box will display the name of the realm in which the document resides, and ask the user for a username and password. Once obtained, the client will make the same request again, only this time it will include the credentials. But as far as the end user is aware, that first request was completely invisible and never happened.
If the client gets a "not authorized" status in response to a request that included credentials, it typically responds a little differently: it will probably tell the user, "those credentials weren't accepted, want to try again?" It didn't say that the first time because it hadn't sent any.
In either case, if the end user opts to not fill in the dialogue and presses cancel, the client typically just displays the error page that the server sent along with the "not authorized" status and goes back to waiting for instructions.
- Skip Ahead
- 1. Maxwell's Demon and Hat Colour
- 2. Maxwell's Demon and Hat Colour
- 3. Maxwell's Demon and Hat Colour
- 4. Maxwell's Demon and Hat Colour
- 5. Maxwell's Demon and Hat Colour
- 6. Maxwell's Demon and Hat Colour
- 7. Maxwell's Demon and Hat Colour
- 8. Maxwell's Demon and Hat Colour
- 9. Maxwell's Demon and Hat Colour
- 1Linux Top 3: Fedora 24, Peppermint 7 and Solus 1.2
- 2Linux Top 3: Alpine Linux 3.4, deepin 15.2 and Linux Lite 3.0
- 3Linux 4.7 Set to Boost Live Patching, Security and Power Management
- 4Linux 4.6 Charred Weasel adds USB 3.1 Support
- 5Linux Top 3: OpenIndiana 2016.04, Ubuntu 16.04 and Debian's New Leader