User Authentication as a Web Application
As always, before we jump in and start using the server behaviors that create the authentication framework, it's important to understand at least conceptually how they work. Users can only access restricted pages once they've successfully logged in. To log in, a user supplies a username and password combination. ASP or ColdFusion queries the database to see if any records contain both the username and the password together. If it does, the log-in is successful, and the user is flagged as having logged in (more on that in a moment). If there are no records with both the username and password, the log-in fails, and the user is redirected to a page indicating that log-in has failed.
Each restricted page has a script at the top that checks to verify that the user is logged in, and if so, processes and displays the page. If the user is not logged in, she or he is typically redirected to a page that enables log-in, and the restricted page never actually loads.
With one exception, you can probably understand how all this could happen in ASP or ColdFusion. That exception is the notion of flagging a user as logged in and checking for that flag across multiple pages. Because the server forgets the user in between every page, setting and checking for the existence of the logged-in flag is problematic. You've overcome the server's forgetfulness in previous lessons by sending URL (or querystring) and form variables between pages. But these solutions are temporary, requiring you to manually send data to every page that needs it. What's needed is something more persistent.
You already worked with one type of persistent variable: the cookie. As you'll recall, a cookie is a name-value pair stored on the user's hard drive and sent to the server when the user makes an HTTP request. Using this technique, you can simulate the effect of the server remembering a user across multiple pages, simply by having pages use and respond to cookie data.
In large part to facilitate applications that need to keep track of users and data over time, both ASP and ColdFusion have special built-in features that handle much of this work for you. These features include, among others, two new variable scopes: application variables and session variables.
Application-scoped variable data: Application-scoped variable data includes any variable information that you want to set for the entire application, regardless of user. For example, if you want to specify a contact person on every page of the site, rather than hard-coding that person's name and email address onto every single page, you can define the name and address once as an application variable and bind that value to every instance of a contact address in the site. Then, if that person is replaced, you need only to change the name in one place, and the rest of the site is updated.
Session-scoped variable data: Session variables contain information for a single user in a single session. If the user leaves the site or closes the browser for a period of time (usually about 20 minutes), then the session ends, and the information is flushed from memory.
Clearly, the session variable is perfect for handling the log-in flag. That is, once a user successfully logs in, a session variable is set indicating the successful log-in. Each page that restricts access needs merely to check for the presence of this session variable to determine whether to grant access to the page or redirect the user to a different page.
The critical concept here is persistence. Through these enhanced application features, ASP and ColdFusion enable developers to create sites where data persists for a certain period of time, overcoming the intrinsic limitation of the stateless HTTP protocol. This persistence is crucial in many applications, not just user authentication. Imagine a Web shopping cart that forgot who you were between the pages where you entered your shipping address and credit card information! You could pay for merchandise that is then sent to someone else.
For the data to be persistent, it must be stored somewhere. Where it is stored depends on the scope of the variable. Application-scoped variables are stored on the server, typically residing in memory. For this reason, you should keep your application-scoped variables to a minimum.
Session variables, in contrast, are typically stored on the user's computer. When you create session variables, ASP and ColdFusion quietly store them as cookies on the user's computer, and then retrieve these cookies as users work through the site. This conversion is usually invisible to the developer; that is, while you may set and retrieve session variables, for example, you won't be both setting and retrieving cookie variables, because that happens behind the scenes.
To enable all of this functionality, both ASP and ColdFusion recognize the collection of pages that make up your site as a single entity, an application. Different pages are part of an application when they have access to the same session and application data. You can't see the whole application anywhereit's not a tangible entitybut it's there. Web applications consist of sets of files that ASP or ColdFusion manages as a group.
Both ASP and ColdFusion have a special page where you can put application-related data and scripts. ASP has global.asa, and ColdFusion has application.cfm. Although these two files are different in many particulars, their roles are comparable. Both handle application-scoped variables and events, as well as session management. Any variable, script, or functionality you add to global.asa or application.cfm is included in and available to every ASP or ColdFusion site within the same application. In most cases, global.asa or application.cfm resides in the site's root directory and therefore the application's scope is the entire site.
From even this brief overview, you can understand why an application framework is so important to authentication. It enables a single entry through a log-in page to provide access to multiple pages, without requiring the developer to manually create scripts that send the data from each page to the next.
