Log Out User

Of course, we need to give our users the option to logout. However, forget the server behaviors for a second -What does Log In User do? It does nothing but authenticate a username and password against the users table and then stuff the username into a session. This session is the key, as it gives the opportunity to personalize the user's experience as long as we have stored a unique identifier for the user, which in our case is the username.

On this note, logging a user out is nothing but simply clearing the session. As you know from chapter 5 you can clear a session using Session.Abandon or Session.Contents.Remove(). The Log Out User behavior does this for us. It clears the MM_Username session and if we restricted access based on Username, Password, and Access Level when applying the Log In User behavior, it adds code to clear the MM_UserAuthorization session. It also gives us two options - it can log a user out but keep them on the same page, or it can sign a user out and redirect them to another page. We will do it the latter way.

Create a new page called logout.asp, and add hyperlinks that point to logout.asp on all pages that you want to be able to log out from (we have just put one on categories3.asp, and labeled it "Log Out".)

On logout.asp, select Server Behaviors > + > User Authentication > Log Out User. When the dialog box opens click the second radio button labeled Page Loads. When done, redirect to login.asp, as seen here:

Test your pages in a browser - log in and surf your web pages; sign out when you are ready. You will be redirected back to login.asp.

Restrict Access To Page

Now that we have the login application working, we can restrict access to pages based on user logins. For example, we can disallow access to certain pages. You will recall that we restricted access based on Username, Password, and Access Level (the Access Level parallels the access_group column stored in the database).

If you look at the users table you will see that users have different values for the access_group column. Only "omar" has the value "admin", while others have the value "member". This is how the author chose to identify access levels - you could add more access levels and use different values; you could even use numbers if you wanted.

Some sites don't require access levels as there may be no need for them - for example, if all users will have access to the same information, there is no point.

However, it is good to learn this concept because it is often needed. We use the access_group column to simply give each a user a level of power. "admin" means the user is an administrator, and should have full site access, while a mere "member" should not have access to certain site functions, such as inserting, updating, and deleting categories or books. Let's test this out now - we will modify our site so that only "admin" users will have access to the update and delete pages.

Before we begin using this server behavior make sure you are logged out (login sessions are cleared).

Open the edit_book.asp page and select Server Behaviors > + > User Authentication > Restrict Access To Page to bring up the following dialog box:

Select the second radio button labeled "Username, Password, and Access Level". Define and then highlight the access group values you want to have access. Hit the Define button, when the Define Access Levels dialog box opens, click the plus sign (+) to add your access group values. It will only allow access to those who have the text "admin" in the access_group column. If a user gets denied redirect him or her to the login.asp page. Hit OK.

Close this document and open the delete_book.asp page. Now go through the same steps as above to give this page the same access restrictions as edit_book.asp.

Now that we have restricted access to our pages let's test it out - load your categories3.asp page and try to edit or delete a book - you should be redirected to the login.asp page. Also, try logging in as a user who is not an administrator (for example, username "superman", password "sup432" and try to edit or delete a book - again, you should be redirected to the login.asp page.

You may also be wondering how to make it so that mere "members" can't even see the functionality that they won't be allowed to use, such as the "edit" and "delete" links, and the form for inserting new books. You would rather only show them to administrators, right?

You can use your knowledge of VBScript conditional logic to show the links only to users whose MM_UserAuthorization session equals "admin". You can surround the functionality that you want to hide from "members" with the following code:

(For a refresher on VBScript Conditional Statements see Chapter 5.) Next time around you may decide to put the insert record form on a separate page to the existing records, and simply restrict access to them. You have now safeguarded the administrative options of your site by giving access to them to administrators only, all with a few server behaviors.

Check New Username

I will not be demonstrating use of the Check New Username server behavior because it works with a user registration form, the likes of which we have not yet created (you will have to wait till the next chapter for this).

For example, when you create an Insert Record form to allow users to create a record in the users table you can simply apply this behavior and it will allow you to redirect users to a specified page if a particular field value inputted by a user already exists in a particular field. For example, it can stop a user choosing a username that someone else is using already. The Check New Username dialog box looks like this:

Summary

In this chapter, we have learned:

·       How to use the Application Panel efficiently while building dynamic content

·       How to create a connection to a database

·       How to use the Bindings window to store and display the dynamic variables you may create throughout your site

·       How to use Server Behaviors and Application Objects to generate large blocks of ASP code

We used a wide variety of the server behaviors available in Dreamweaver MX to create a simple but effective online content management system. This chapter has demonstrated some of Dreamweaver MX's more powerful features - we hope you are now fully equipped to start creating your own database applications.

However, it's not over yet. In the next few chapters we will show you how to use Dreamweaver MX to build some more complex complete web applications.