Many of my articles in this column have dealt with theoretical concepts and syntax of implementing those concepts in ColdFusion. In this article, I want to concentrate on the implementation steps you might take when building something.

Most Web applications have a "sign me up" feature that allows users to register. Registered users often have access to additional information or features that anonymous users don't. I'm going to walk you through the process of creating a simple login form, including database authentication and a "remember me" checkbox.

The Database
Before you start coding this application, you'll need to create a database. Most login schemes include a username and password. You can put that information in a table called Users. The table will also need a unique identifier, called a primary key in database terms. Here is a sample of data from the table:

UserID	Username	Password
1	Jeff	Houser
2	CFDJ	Author
3	ColdFusion	Macromedia

Normally, a users table would have much more information than just a username and password. A name, address, and e-mail address are common additions. For the purposes of this example, we'll keep it simple. In a real-world application, you should consider encrypting the passwords in your database for security purposes. You can do this using ColdFusion's hash function. More information about the hash function is located at Click Here. You would use the hash function before saving the user's password into the database. For the purposes of this example, the passwords will remain in plain text.

You could implement a login script using just the users table we defined, but you'll find it limiting. The user is either logged in, or not logged in. There is no distinction between different levels of access. Suppose, for example, that anonymous users can look at products, registered users can post reviews of products, and admin users can change product information. You'll need something more than an "Authenticated" or "Not Authenticated" security structure. To do this we'll need to be able to group users into security groups. The SecurityGroups table will need a primary key and a group name. This is an example of some possible groups:

GroupID	GroupName
1	Admin
2	Anonymous
3	Registered

You'll also need an intersection or linking table to associate a user with his or her groups. This table will contain the GroupID and the UserID. The reason for creating this as a separate table is so that a single user can be in multiple groups, and a single group can have multiple users inside of it. This is known as a many-to-many relationship in the world of database design.

Here is an example of the SecurityUserGroups intersection table:

GroupID	UserID
1 (Admin)	1 (Jeff / Houser)
3 (Registered)	1 (Jeff / Houser)
3 (Registered)	3 (ColdFusion / Macromedia)

I added the group and user names next to the ID in parentheses to more easily show the relations. In a relational database, you would store only the ID. Our finished database structure is seen in Figure 1.

Before accessing this database from your ColdFusion code, you'll have to create a datasource in the ColdFusion administrator. Setting up the datasource is beyond the scope of this article, but it's a pretty straightforward task and you can read about setting up datasources for any database at Click Here.

The Login Form
With our database ready for use, we can start examining the login form. Most forms have two parts: an input page and a processing page. The input page asks for the username and password. It also has a checkbox for a "Remember Me" functionality. The code behind the form is shown in Listing 1.

The login form can be seen here: (Figure 2)

Enter Jeff in the username field and Houser in the password field. Check the Remember Me box and click submit. This brings us to the processing page (see Listing 2).

The RememberMe form variable value comes from a checkbox. If not checked when the form is submitted, the variable will not exist on the form processing page. You can use the cfparam tag to default if this situation occurs. The second step in the process is to validate the user's login information against the database. The cfquery tag is used to run the database query. The query joins the users table and the SecurityUserGroups table, where the username and password fields are equal to the input of the form. The query retrieves all information from the users table and the list of GroupIDs from the intersection table. If the database stored hashed passwords, we would change the query comparison to:

Users.password = '#hash(form.password)#'

This allows us to correctly compare two hashed values, not plain text passwords. This way we are keeping the user's password information secure.

We can check the RecordCount variable of our query to see if the query returned any rows. If the query did not return any rows, then the user did not enter a valid username and password combination. The login should fail. If rows are returned, then the login was a success. The code creates two session variables to process the login. To make use of session variables, you'll have to use the cfapplication tag. ColdFusion's application framework is beyond the scope of this article; however, you can read about it at Click Here.

The first value, LoggedIn, is a Boolean value that specifies that the user has logged in. I would default this value to false when the session is initialized. The second variable, groups, contains a list of all the groups that the user is in. The ValueList will give us a list from the column in the query.

Later in your application, when you have to decide whether a user should have access to a resource or not, you can use ListFind against the groups variable to see if the user is allowed. Here's an example:

<cfif ListFind(session.Groups, 1)>
 allow Access
<cfelse>
 No Access
</cfif>

If the user is in the admin group he or she can see the resulting HTML code, or access the corresponding resource. If not, then he or she will not be given access.

In this code, we are rolling our own security scheme. Many applications will use this approach, due to the complexity of security functions in the pre-CFMX days. However ColdFusion MX introduced a much improved security scheme using some new tags: cflogin, cfloginuser, and cflogout. They allow you to log in a user and set up a list of roles that ColdFusion will handle internally. The roles tie in with the role attributes of functions inside a ColdFusion component. These new tags are not in wide use yet, but they are definitely worth checking out if you are building an application from the ground up (livedocs.macromedia.com/coldfusion/6.1/htmldocs/appsecu6.htm). The reason I don't use them in my development is because my biggest project of the moment is being built to run off of BlueDragon, which does not yet support the functions.

Remembering the User
The one portion of code that I haven't explained yet is the "remember me" portion, so let's look at it in detail. There are many different ways you could implement the "remember me" portion of code. In most methods, you'll set a cookie on the user's machine, and store the same value in the database. When the user returns to the site, you can check to see if the cookie exists. If it does, you can retrieve the user's information from the database based on the cookie value. Simpler systems where security is not an issue may store the user's primary key ID. More complex systems with heavier security requirements may assign a UniqueID value, created with the CreateUUID function. Some systems I've worked with will store the CFID and CFTOKEN values generated by ColdFusion and used for session management, and use those to remember the user.

For the purposes of our sample, we are going to store the user's primary key as a cookie, but remember that in applications where security is a priority, this is probably not your best move. If form.RememberMe is set to true, then we use the cfcookie tag to create a cookie on the user's browser. We name the cookie UserID. The value is set to the UserID value returned from the query. It is set to never expire.

Setting the cookie is only the first step. When a user comes to the site, something will have to be implemented to check to see if we know who they are, or not. We are going to put this code in the Application.cfm. The code in the Application.cfm will look like an abbreviated version of the code in the login-processing page (see Listing 3).

First the code checks whether the IsLoggedIn session variable is defined. If it isn't, then this is the first time a user has come to the site. Next, we check if the UserID cookie variable exists. If it does, Next we run a query to get the user data based on the UserID. If the query finds the user, the code sets the two session variables. If not, it defaults them to the value. If the cookie doesn't exist at all, it defaults the session values.

Conclusion
This article demonstrated a simple method for implementing a login script on your site. It incorporated many common security elements and used many common ColdFusion tags. The approach I took in this article is not the only approach that could be used, but it is simple yet elegant. For those who want more, you can check out the authenticationAPI included in Macromedia's DRK 7. In my next column I'll talk more in depth about ColdFusion's application framework and the cfapplication tag, including setting up the session and application scopes.