24.1 Password-Protecting Web Pages

Although Dreamweaver lets you create Web pages that can add, edit, and delete records from a database, your ebusiness wouldn't last very long if just anyone could remove orders from your online ordering system or view credit card information stored in your customers' records. And certainly your company's executives wouldn't be happy if someone accessed the staff directory database, and changed their titles from, for example, CEO to Chief Bozo. For these and other reasons, Dreamweaver provides a simple set of tools for locking your pages away from prying eyes.

The User Authentication server behaviors can password-protect any page on your site. With this feature, you can limit areas of your site to registered users only, allow customers to access and update their contact information, create maintenance pages accessible only to administrators, or personalize Web pages with customized messages ("Welcome back, Dave").

To password-protect pages on your site, you'll need to get several elements in order:

• A database table containing user login information.

• A registration form for adding new users. (This is an optional step, but it's frequently useful when you want to automate the process of adding user login information to the database.)

• A login form.

• One or more pages that need to be password protected.

24.1.1 The Users Table

Your database must hold several pieces of information. For example, each visitor must have a user name and password to type in when he attempts to log into your site. If the name and password match a record in the database, then he's logged into the site and can access password-protected pages.

You might also need to include a field in the record for assigning an access level to each person. This way, your site can have multiple sections accessible by different groups of people. Dreamweaver provides tools not only to require a proper name and password, but also to allow access to only those with the proper clearance level.

For example, if your site has a members-only section that affords registered visitors extra content or special features, you could assign everyone who registers the level of "member" and give them access to these pages. However, you only want your site's administrators and staff to be able to update a product database or retrieve sales records, so you would give these users a level of "administrator" for access to these areas.

At a minimum, then, your database needs a users table with three fields (user name, password, and access level). You can either use a standalone table or incorporate this information into another table. For example, if you require people to provide their name, address, email address, and so on when registering with your site, you could include the three login fields in this table. For an ecommerce system, login information could be stored in the table holding customer information.

Most database systems let you assign a default (proposed) value to a column. That way, when someone creates a new record and supplies no information for the column, the application enters the default value instead. For starters, it's a good idea to assign a default value for the access-level field. You can set your database to assign the lowest access level?guest," say—whenever someone creates a new user record. In this way, if you use a Web form for collecting and creating a new user, you can omit a form field for assigning an access level. This method is a good security precaution, as adept (and malicious) Web users could submit a fake form with a higher access level, potentially granting them access to sensitive areas of your site.

24.1.2 Creating a Registration Form

Once you've added a users table to your database, you'll need a way to add new users. If you plan to use password protection for sensitive pages that only your site's staff should access, you probably shouldn't create a Web form for adding new administrative users. You'd run the risk of someone finding the form and adding herself to the list of administrators. In such cases, you're better off adding the proper login records in the database system itself—using Microsoft Access, for example.

If you do create a Web form for adding new users with a high access level, password-protect this form! Otherwise, anyone stumbling upon it could add new administrative users—and from there, Pandora's Box would be open.

On the other hand, if you want to let lots of people sign up as members of your site, you might want to add a registration form that automatically adds them to the list of the site's users. This setup would free you from the headache of assigning user names and passwords for everyone who wants to become a member.

If the site already includes a form for collecting visitor information, you can simply add the proper user fields to this form. Say your site includes a "Sign up for our email newsletter" page that collects a visitor's name, email address, and other contact information. You could add a field called user name and another called password.

It's commonplace to use an email address as a person's user name for password-protected pages. If you're already collecting an email address, exclude the user name field from the form.

When the visitor submits the form, the Web application adds all of these fields to the database. (To add records to a database using a Web form, see Section 23.1). While the process of creating a new user for password-protected pages is basically the same as adding a new record to a database, there's one additional step: You must make sure that every visitor has a unique user name.

Dreamweaver's Check New User Name server behavior ensures that each user name submitted in the form is unique. If the name already exists, the server won't add the new record to the database and will redirect the visitor to another page. To apply this server behavior, follow these steps:

When adding a new user to your database, the Check New Username server behavior lets you verify that the user name isn't already in use by another person.

Dreamweaver MX 2004 now provides access to all user-authentication server behaviors from the Applications tab of the Insert bar.

After inserting the server behavior, Dreamweaver lists it in the Server Behaviors panel. If you wish to change any of its properties, double-click its name in the panel to reopen the Check New Username window (Figure 24-1). To delete the behavior, select it in the Server Behaviors panel, and click the Remove (-) button.

24.1.3 Creating the Login Page

To access a password-protected page, your visitor must first log into the site using a Web form. This simple Web form should contain just two fields—a user name field and password field—and a Submit button.

When someone attempts to log in, the values she types into the form are compared with the user name and password columns in the database. If there's a match, then she's transported to another page—often the main page of a password-protected area of the site. If there is no matching record, then the visitor is carted away to a page of your creation—an "Access Denied!" page or maybe just the original login page.

To create a login page:

Dreamweaver's Log In User server behavior gives visitors a way to log into your Web site, so they can visit password-protected pages. There are quite a few items to fill out here, but they're all straightforward. The last option lets you use access levels to limit pages of the site to particular groups of users—administrators, for example.

You can edit or delete this behavior by double-clicking its name in the Server Behaviors panel.

24.1.4 The Log Out User Behavior

Dreamweaver's Log Out User server behavior lets someone log out by clicking a link. Thereafter, her Web browser won't be able to load any password-protected pages in the site until she logs back in.

This setup is useful when a visitor shares her computer with others, maybe at the library or school, because it provides a sense of security to visitors who see that they have the ability to log out. (It's not technically necessary, though; her computer destroys the session variable used to keep track of her login status anyway, as soon as she quits her browser. Furthermore, if a certain amount of time passes without any activity—usually 20 minutes—the Web server automatically destroys the session variable, effectively logging out the user anyway. Again, though, a logout link can be reassuring to your audience.)

To add a Log Out server behavior:

POWER USERS' CLINIC Logging In: Behind the Scenes The Log In User server behavior checks to see if the user name and password submitted by a form matches a user name and password in the database. If it does, the behavior generates two session variables (Section 24.2.7): MM_Username and MM_UserAuthorization (in the PHP/MySQL server model, these are MM_Username and MM_UserGroup). The first one stores the user name of the logged-in visitor; the second stores the access level of that user. (The MM stands for Macromedia, since programs written by Dreamweaver engineers create these session variables.) The variables follow visitors from page to page of the site, until they log out, close the browser, or don't do anything on the Web site for at least 20 minutes. The password-protection scripts use these session variables to allow or deny access to a page. But you can take advantage of these variables in other ways. You can add MM_Username to the Bindings panel (see Section 22.2.1), for example. You can then add it to your pages like other dynamic data for customized pages: "Welcome back, Kotter176@aol.com." Furthermore, since each user name is unique—just like a primary key—you can use the session variable to filter records in a recordset (Section 22.1.3). You could use this technique, for instance, when a logged-in user wishes to see all of his contact information. Create a recordset that filters the user table by the session variable. You can also use the MM_UserAuthorization variable (MM_UserGroup for PHP) to control the display of certain areas of a page. For example, while regular members of your Web site might see a simple listing of products on a dynamic catalog page, administrators might see additional items like "Edit this product" and "Delete this product" buttons. The tutorial in this chapter has an example of this scheme in action (Section 24.4.3).

There are several ways a visitor can log out. You can log him out when a page loads or when he clicks a link. You'd use this behavior when you want to automatically log someone out when they reach a specific page. For example, say you create an online testing application, where students would sit at a computer and answer page after page of questions. When students reach the last page of the quiz—maybe a page summarizing their results—you could automatically log them out. The next student sitting down at the same computer would have to log in, preventing the testing application from thinking the new test taker is the same person as the previous student.

Most Web sites let visitors log themselves out by clicking a link, so the menu starts out reading, "Create new link: 'Log out'," which adds a new link with the words "Log out" to the page. After adding the behavior, you can then edit the page and change Log out to any text you like, or even add a graphic button to the link.

To add a logout function to text or an image that's already on a page, simply select it and then apply the Log Out User server behavior.

24.1.5 Protecting Individual Pages

To password-protect a Web page, apply the Restrict Access to Page server behavior. You have to do this for each page you wish to protect, and you can only apply it to dynamic Web pages. In other words, you can't password-protect regular HTML files, text files, graphics, or any other file that isn't first processed by the application server.

The Restrict Access to Page behavior works like this: When someone attempts to load a password-protected page, programming code in the page determines whether he's already logged in. If the page also requires a particular access level—administrators only, for instance—it checks to see whether the visitor has the proper clearance; if so, then the browser displays the page. If the visitor isn't logged in, however, or doesn't have the proper access level, then he's redirected to another page—like an "Access Denied" page or the login page.

To apply this server behavior, proceed as follows:

If you want to give access to more than one group, you can Ctrl+click (-click) more than one level in the Select Levels list to highlight them simultaneously.

Like the other server behaviors, Dreamweaver lists the Restrict Access to Page behavior in the Server Behaviors panel after it's applied. If you wish to change any of its properties, double-click its name in the panel. To delete the behavior, select it in the Server Behaviors panel and click the - button.