| The rest of this chapter discusses how to build your own form-based security mechanism. In general, putting such a mechanism in place requires three basic steps: - Deciding which pages or information should be password-protected
- Creating a login page and verifying the user name and password
- Restricting access to pages or information based on who the user is, either using a homegrown Session-Based mechanism, or with the <cflogin> framework
Deciding What to Protect First, you have to decide exactly what it is you are trying to protect with your security measures. Of course, this step doesn't involve writing any code, but we strongly recommend that you think about this as thoroughly as possible. You should spend some time just working through what type of security measures your applications need and how users will gain access. Be sure you have answers to these questions: Does the whole application need to be secured, or just a portion of it? For company intranets, you usually want to secure the whole application. For Internet sites available to the general public, you usually want to secure only certain sections (Members Only or Registered Users areas, for instance). What granularity of access do you need? Some applications need to lock only certain people out of particular folders or pages. Others need to lock people out at a more precise, data-aware level. For instance, if you are creating some type of Manage Your Account page, you aren't trying to keep a registered user out of the page. Instead, you need to ensure that the users see and change only their own account information. When should the user be asked for their user name and password? When they first enter your application, or only when they try to get something that requires it? The former might make the security seem more cohesive to the user, whereas the latter might be more user friendly.
We also recommend that you think about how passwords will be maintained, rather than what they will protect: Should user names and passwords become invalid after a period of time? For instance, if a user has purchased a 30-day membership to your site, what happens on the 31st day? Does the user need the option of voluntarily changing their password? What about their user name? Should some users be able to log in only from certain IP addresses? Or during certain times of the day, or days of the week? How will user names and passwords be managed? Do you need to implement some form of user groups, such as users in an operating system? Do you need to be able to grant rights to view certain items on a group level? What about on an individual user level?
The answers to these questions will help you create whatever database tables or other validation mechanics will be necessary to implement the security policies you have envisioned. You will learn where and when to refer to any such custom tables as you work through the code examples in this chapter. |