At this point, we've covered how to secure your computer system and the database. That portion of security doesn't involve Dreamweaver MX, obviously, but is important. Now let's explore adding security to your individual web pages-that is, restricting access to your site and your site's pages by allowing only users who have the proper permissions to access your pages.
Before you can properly secure or restrict access to your website, you need to know who is trying to log in. Dreamweaver MX provides a quick method for creating a login page and verifying that the user is who they claim to be. Using the User Authentication Server Behavior, you simply point to your database, choose a couple of field names, and then save your new login page. Let's take a look at how to do it.
First, you need a database that contains the proper user information along with username and password fields. For our purposes, we're going to use the tblBorrowers table from the Books database. This table includes two database fields with the names of Username and Password. If you're not using the sample database on the CD, make sure your database has fields corresponding to the username and password information. (For this example, we're assuming you've already established a database connection through the Databases tab of the Application panel. For more on how to do this, see Chapter 2.)
Next, let's create a simple form with two text fields in which the user will type a username and password. Figure 17.12 shows our version containing a table with the two text fields appropriately named. You'll also want to create two more pages, one to which the successful login will take the user and the page that the unsuccessful login presents. We're calling ours Welcome.asp and LoginFailed.asp, respectively.
Figure 17.12: Although this form isn't pretty, it contains the required elements for a login page.
Next, we're going to add the User Authentication Server Behavior to this page. Just as with the other behaviors in Dreamweaver MX, adding this behavior pops up a window into which you specify the proper field names and so forth. To add the behavior, click the plus sign (+) on the Server Behaviors tab of the Application panel, as we did in Figure 17.13, and choose User Authentication ® Log In User to open the Log In User dialog box shown in Figure 17.14. We've filled ours out, as you can see.
Figure 17.13: Dreamweaver MX lets you quickly build a login form.
Figure 17.14: Choose the proper login options in the Log In User dialog box, and Dreamweaver MX will do the rest.
Dreamweaver MX doesn't inherently include the User Authentication Server Behavior for PHP (Hypertext Preprocessor) or ASP.NET. However, from the Macromedia Exchange for Dreamweaver you can download a PHP user authentication behavior created by Felice Di Stefano. Log in to the Macromedia Exchange and search for PHP User Authentication. For more information about adding extensions to Dreamweaver MX, see Chapter 24.
If you don't see User Authentication, you may first need to save your page with an extension so that Dreamweaver MX knows which language to use. Once you do, click the plus sign (+) on the Server Behaviors tab, and you should then see User Authentication. Dreamweaver MX doesn't show you some of the behaviors until it knows which type of page you're creating-ASP, ColdFusion, and so forth.
Enter or choose the settings for the following fields:
Get Input From Form Choose the form's name from this drop-down menu.
Username Specify the text field on your form that corresponds to the username entry.
Password Specify the text field on your form that corresponds to the password entry.
Validate Using Connnection From this drop-down menu, you'll need to select the database connection that contains the table with username and password fields. When you do, Dreamweaver MX will look up the fields and add the fields to the next three drop-down menus.
Table Choose the proper table from this drop-down list.
Username Column Choose the table column that contains the usernames.
Password Column Choose the table column that contains the passwords.
If Login Succeeds, Go To Enter the name of the page the user should see if they log in successfully.
If Login Fails, Go To Enter the name of the page the user should see if their login fails.After you complete the fields, click OK and save your page. That's all there is to creating a login page. Test your page by attempting a login with a proper username and password and then with an improper set. You should see that indeed your pages redirect just as you'd hoped. That was easy!
Suppose that you need to restrict page access based on security levels. Dreamweaver MX allows you to quickly build that kind of behavior as well. We'll explore that next.
Once a user logs in, you might want to restrict them to particular pages. Perhaps this person shouldn't see administration pages, or maybe they should see pages that only pertain to them. Dreamweaver MX will let you quickly build pages that restrict access in two ways. You can simply test whether the user has logged in, or you can restrict access based on varying levels you set.
In Chapter 20, we'll be creating an Update Category Data page. We're going to apply access rights to that page in our next couple of examples. First, we'll add the method for just testing logged-in status. We do this in the same manner as the prior method we mentioned-through the Server Behaviors tab. Follow these steps:
Click the plus sign (+) on the Server Behaviors tab on the Application panel and choose User Authentication to open the Restrict Access To Page dialog box, shown in Figure 17.15.
Figure 17.15: You can test for whether the user is logged in or whether the user meets specified level criteria.
For this first example, choose the first option, and then enter into the If Access Denied text box the name of the page to which the user should be taken if they don't have rights to view the page.
Save the page, and then test it.
If you've previously logged in, the server may remember that and let you in. So we'll build a log-out page next. (We'll get to restricting access by levels in a moment.) If you weren't allowed in the Book Category page, you should be taken to your NoAccess.asp page, as we were, as you can see in Figure 17.16.
Figure 17.16: Our login failed, so we see our No Access page.
The Dreamweaver MX login and access right behaviors work by using session variables. Session variables are special web server variables that keep track of a user's time on your site. Session variables only exist while the user is logged in and active. If the user leaves the site or doesn't perform any action for a period of time dictated by the web server (and the system administrator), the server erases the session variables and effectively logs the user out.
To create a log out page and clear the user's session variables, follow these steps:
Create a new page called Logout.asp or something appropriate.
To add the Log Out User Server Behavior, click the plus sign (+) button in the Server Behaviors tab of the Application panel and choose User Authentication ® Log Out User to open a dialog box similar to that in Figure 17.17.
Figure 17.17: Dreamweaver MX will automatically create a log out script for you.
You can have the log out procedure execute when the page loads by clicking Page Loads or, as we did, by having Dreamweaver MX add a Log Out link to the page for us.
Enter a page that the user should be taken to when they log out, typically back to the login screen, and click OK.
Save your page and load logout.asp. You should see something similar to that in Figure 17.18.
Figure 17.18: Our log out screen will remove our session variables and take us back to the login screen.
Once you log out, try to load the BookCategory page again. The system shouldn't let you in because you've just logged out. Now, suppose you want to allow people with administrator rights to access the BookCategory page, since they might want to make changes to the database, but you want to keep everyone else out. Dreamweaver MX will let you do that easily too.
Let's modify our BookCategory page and restrict user access rights by levels. To do that, we need to go back to the actual login page, because the access rights are pulled from the same table that contains the username and password. Follow these steps:
Go back to your login screen and double-click the Log In User Server Behavior that you added earlier to open the behavior so that you can modify what you've already entered. This time, we're going to select username, password, and access level, as you can see in Figure 17.19.
Figure 17.19: This time, we're going to use security levels in our login process.
From the Get Level From drop-down list box, select the field that contains your user security levels. We added a field called SecurityLevel that contains Admin, Power, and User as the varying values among our users, so we select the SecurityLevel field.
Click OK and save the page.
Go back to your BookCategory page and double-click the Restrict Access To Page Server Behavior so that you can modify it.
Select the Username, Password, and Access Level links.
Click the Define button to open the Define Access Levels dialog box, as shown in Figure 17.20.
Figure 17.20: You specify the levels to which you want to give access to this page.
Add the levels that you want to give access to by typing them in the Name text box and clicking the plus sign (+).
The names that you enter here must already exist in the table you specified back in your login screen. For example, since we specified Admin, Power, and User as our varying levels of access, we have to enter any of those three levels here. If we enter a name that doesn't exist in the table, SuperUser, for example, the page won't let us have access. We're going to add Admin as the only level that should have access to this page.
Enter admin, and click OK. Now our Restrict Access To Page dialog box looks like that shown in Figure 17.21.
Figure 17.21: We've just given Admin-level users access to this page.
Save your page and log back in through your browser.
We're going to log in as Susan, since our database has Susan listed with a level of Power. When we try to load the BookCategory page, the system won't let us in, as it shouldn't. Now, log out and log in as Darren. Since Darren has the level of Admin in the database, we succeed when we try to access the BookCategory.asp page.
As you can see, Dreamweaver MX provides some powerful functionality with only a few mouse clicks and a small amount of typing. The User Authentication Server Behaviors provide an excellent way to apply security to your web pages.
Suppose you want users who don't have a login username and password to be able to register on the site as well. You'll need to make sure that usernames are unique among your users, and since you certainly don't want to manually check every name visitors could enter, you need to ensure that usernames are unique programmatically. Dreamweaver MX can help you with that as well, through the Check New Username Server Behavior.
Let's modify our system a bit to provide a smooth flow between our login, registration, and new username pages. We'll be adding the registration form to this mix, so let's start with it.
The registration page is basically just a form from which we'll insert data. The exception is that we'll add the Check New Username Server Behavior to this page as well. So let's start with an insert form, similar to that in Figure 17.22. We're adding fields to this form that correspond to the important user information from our table. And, since this table houses a security level as well, we're adding a default hidden field called Level that we're setting to the value of User.
Figure 17.22: Registration starts with an insert form.
After you create your form, follow these steps:
To add the Insert Record Server Behavior click the plus sign (+) on the Server Behaviors tab of the Application panel.
Choose Insert Record to open the Insert Record dialog box, as shown in Figure 17.23, and enter the appropriate information, making sure that the fields in Form Elements map correctly.
Figure 17.23: We use an Insert Record Server Behavior as the first step in our registration page.
Click the plus sign (+), and choose User Authentication ® Check Username to open that the Check New Username dialog box, as shown in Figure 17.24.
Figure 17.24: Specify your user- name field and the page the user should see if the username exists.
From the Username Field drop-down list box, select the field that contains your username, and then enter a page that the user should see if the entered username is already on file.
Test your page by entering information into the Registration form. If you're using our sample database, you can enter what we have in Figure 17.26.If not, enter some new user information then save it.
Figure 17.26: We're entering a "new" user's information.
Go back and reenter the same username to force a duplicate error. Click Submit, and you should see the notice shown in Figure 17.27.
Figure 17.27: Dreamweaver MX found our username to be duplicated, so it's sending us to our notification page.
Network, database, and Internet security are the subjects of far too many books, magazines, online discussions, and so on to list here. A good comprehensive source from the publisher of this book is Mastering Network Security (2nd edition), by Chris Brenton and Cameron Hunt (Sybex, 2002). If you're implementing security in a Linux environment, check out Linux Security (Craig Hunt Linux Library), by Ramón J. Hontañón (Sybex, 2001).