Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL

Chapter 12. Authentication and Authoriza... > An Authenticating Script for IIS - Pg. 302

Clearly we need to do more than just check for the presence of an Authorization: header. We'll want to look up the credentials somewhere and decide whether to au- thenticate the user. Having done so, the protected code will be in a position to do more. It could, for example, look up the value of the company field in a requested docbase record and compare that with the list of companies subscribed to by the authenticated user. But before we build that piece, let's look at why this script won't work the same way in IIS and how to fix that. An Authenticating Script for IIS 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 authorization. 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 pro- tected resource, IIS--seeing the incoming Authorization: header--steps in and decides