Before we begin to authenticate users with wild abandon in our web applications, we should think about where, why, and when to do this. We need to have a clear idea of how they are going to navigate around our site.
We must first understand the nature of our web application. If we are writing an online e-mail client (often called webmail) with which users can read, send, or reply to e-mail, we likely have an application with no public areas. Users would have to be logged in and verified by the system before they could use it (see Figure 20-1).
Figure 20-1. Applications that require a login.
An online banking or stock brokerage application is an example of a system with more public content. On this, we have a clearly defined "private area" through which customers access their accounts, but we also now have public areas where anybody can browse and learn things about how to create accounts, what the current interest or mortgage rates are, or where to find a branch office (shown in Figure 20-2).
Figure 20-2. Web applications with both private and public areas.
Finally, our application could be a bit more casual, like a public message board system. On this, users can browse large amounts of content without needing to be logged in, and they would only need to be authenticated to create new posts or reply to existing posts. In this sort of system, the distinction between public and private content is less clear, but we can still come up with areas where we only want to have authenticated users (see Figure 20-3). Note that it is often these latter systems where we are lulled in to a false sense of safety (since they are not as "serious" as banks) and where we pay less attention to worrying about the users' security.
Figure 20-3. Web applications with many public areas and some private areas.
These categories are not meant to be exhaustive. However, they show the range of management and force us to think about how our web application needs to manage its users (if at all).
If you recall from Chapter 14, "Implementing a User Interface," you were told that web application authors should plan their pages in advance to show how users move from page to page. This helps to plan work, understand the scope of the application, and think of design improvements before starting to write code.
This specification process also gives us a chance to decide what pages require the user to be logged in. For an e-mail application, the decision process is not difficultthe application starts with a login page, and all subsequent pages require the user to be logged in. For the banking application, any pages that gave us access to our account information or allowed us to perform transactions would require us to be logged in, while the rest of the pages would not. For a message board system, we might decide that users have to provide only login credentials when they want to create a new post, reply to an existing post, or modify their account information. Otherwise, they should be able to browse through the site.
One last question we might ask ourselves for applications with mixed content is, "Do we want users, once they are logged in, to continue browsing the public areas of the application?" For the message board system, you would probably answer yes. However, for banking applications, we should think about this. To reduce the risk that users might run into security holes in the site that leak their session ID or other sensitive information (see Chapter 19, "Cookies and Sessions"), we might decide that they must complete all of their online banking tasks and log out of the application before continuing on to public areas. This helps to isolate the most sensitive activities to one area and force users to downgrade their access level within the system before continuing on to less critical areas. This limits the possible damage if their session is compromised later.
Regardless of how we decide to implement it, we should at least have the entire system planned in advance and understand which pages require what levels of security before we write any code. A little bit of planning goes a long way.