Insert the code in Listing 2 at the top of an existing page followed by your existing HTML and <BODY> tags or the ASP code. Give the page the same name as defined in the POST action= filename method, which in this case is protect.asp. Then, you can change the password in the If Password= string to your selection. Because the ASP code is server-side code, the password won't be exposed to the user's browser. Be sure not to let users browse this directory because they'll be able to right-click the filename and save the entire contents to a local disk. After users have saved the file locally, they can display the file's contents, including the ASP code and password. If the user enters an incorrect password, the form will continue to reappear, which is preferable over the error message 404 File not found or a Maximum Retries Exceeded error. After the user has entered the correct password, the code redirects the user to the protected portion of the page.
Another method of ASP password protection is to use a password database or password file. This technique presents a form page that requests a username and password from the user. The system compares the username and password with entries in a database or parses a password file for a match. This method is generally more secure than the examples I gave earlier because the ASP code and passwords are stored in separate locations. Many examples of ASP scripts that use a password database are available at ASP code repositories on the Internet.
One final consideration is that you can't let users simply bypass the authentication pages, which means that pages must execute in a controlled order if they don't contain forms that submit to themselves. To prevent this bypass, use session variables or session cookies, and set the page to expire immediately so that the ASP code executes each time the page is accessed. Not doing so might let subsequent users use a cached version of the page to gain access. Caching is one disadvantage of using a session variable: The session stays active until the browser window closes, and anyone who uses the open window can continue to access the secure page.
Using Built-in Windows and IIS Security
Both the JavaScript and ASP code samples are easy to implement, but you can password-protect your Web pages just as easily by using built-in Windows and IIS security features. In a few minutes' time, you can employ user accounts and passwords from the local SAM database to protect chosen pages. In the case of a Win2K system, you can also employ user objects from Active Directory (AD). Windows filesystem security inherently handles all problems with page or file protection and page execution order.
You set up these authentication methods in Microsoft Management Console (MMC). To set up authentication, follow these steps:
- Open MMC.
- Right-click an entire site, a file, or a directory, then select Properties.
- In the Properties dialog box, click the File Security tab, then click Edit. The Authentication Methods dialog box that Figure 1 shows will appear.
- Select the Anonymous access check box to let users access the pages you've selected for this authentication setting.
Before you begin password-protecting your Web pages, note that the disk on which password-protected files and directories reside must be NTFS. You need to verify that the wwwroot partition, in addition to any virtual directories that use IIS password protection, is NTFS. To password-protect your files and applications, follow these steps:
- Right-click the file or application you want to protect, then select Properties.
- Click the Security tab.
- Add the user, users, or group that needs access to the resource. Grant the users or group Read privilege (or Read & Execute if the resource is an application).
- Remove the Everyone group, the IUSR_computername user, and any other users to whom you want to deny access. (If you're protecting a virtual directory, ensure that you add the Administrator group with Full Control before you remove the Everyone group.) A dialog box will appear stating that you can't remove this user because the object is inheriting permissions from its parent. Clear the Allow inheritable permissions from parent to propagate to this object check box, as Figure 2 shows.
- The system will ask whether you want to copy or remove previously inherited items. Because you'll keep the Administrator group and remove all other users and groups anyway, click Copy.
- Before you close the Security window, make sure that the account you're using to manage this resource has Full Control rights or you'll lose access to this item. If you want to apply these settings to the entire directory contents and all subdirectories, ensure that settings can propagate to all child objects.
Register
