As far as Apache is
concerned, the script shown in Example 12.1 has
nothing to do with any of the authentication and authorization
schemes that Apache may be using. The script itself, in other words,
is unprotected. There’s no directive in
httpd.conf that names
/cgi-bin as a protected directory, so
there’s no trigger that causes Apache to issue an
authentication challenge. When a user tries to run the script, it
acts autonomously to provide its own authentication and
If you try the same thing with IIS, though, you’ll find that the script behaves differently. The browser can’t log in with any random credentials, as in the Apache case. It can only authenticate with the credentials of a real user listed in the server’s local domain or in the domain to which the server belongs.
This behavior is arguably a bug. Even though the script isn’t
declared to IIS as a protected resource, IIS—seeing the
Authorization: header—steps in and
decides to authenticate the credentials against the NT domain. Only a
valid domain user—albeit any user!—can pass. It’s not clear what resource IIS thinks it is protecting when it does this. The behavior might be OK if you want to write a script that uses generic domain authentication but then provides its own custom authorization—such as the documents-by-subscribed-company rule that we want to enforce. But it’s not OK if you need to support subscribers who aren’t domain users. Are you out of luck in this ...