Validating Users

For applications where we need to manage user accounts and log users in at various times, we want a system enabled to handle this. While we will discuss the details of how to implement this in Chapter 19 and Chapter 20, "User Authentication," we will discuss some of the design issues here.

Partial Versus Full Logins

Many E-Commerce sites have an interesting behavior by which they offer a personalized greeting message to you, such as "Welcome back, Luigi Marinara, to Bubba's Big Boutique," yet they still require you to log in once you want to pay for the items in your shopping basket. These sites have three types of login:

• Visitors and guests about whom the application knows nothing

• Registered users who have been there before but have not logged in recently

• Registered users we know are currently logged in to the application

The web application distinguishes between the first two groups by using the cookie feature. When users create an account or log in, we can set a cookie associated with their browser that tells us who they are. When they come back to visit the site again (even though we consider their last login to be insecure and invalid), we can offer them a personalized browsing experience. We can also use this to direct them to a personalized home page, as long as it does not contain private and confidential information. However, we will be sure not to trust this identifying information since it is possible that this is a public computer and the users did not clear out all the browser caches before they left the machine. Before granting access to private information, we want to make them log in with their full username and password so we can verify their identity.

Where to Store User Information

Our next decision comes in planning where to store the information for a particular user. The primary options in our web applications would be in the database or in the cookie that we send back to the client. The latter of these would seem quite promising since we can save space on our servers and save all the information on the client's machine. This cookie would be sent back to us every time the client came to visit, saving us from even retrieving the information from the database!

Alas, it is not so convenient. Cookies are better left for ephemeral information, not long-term data. Major flaws with putting the data in cookies would include these:

• Cookies are insecure; they are transmitted as text over the network (unless we are using SSL), and people with network sniffers can read them, including credit card numbers included in them.

• Cookies are part of the information set that most modern browsers can and often do delete on a regular basis. It would be unfortunate if, every time a client "cleaned up" his computer, he found that all his ordering information and history had been deleted.

• One of the most powerful features of the Internet is that users do not have to use the same computer all the time. If they go on vacation in Korea and find an Internet café, they can still visit your web application from there and expect to be able to log in as normal.

• Our last example exposed another flaw: Users of public computers would find all of their personal information stored on public machines that are available for anybody to browse. (Cookies are typically stored in text files.)

With all this information against using cookies, we are left with putting the users' information on the server, most likely in our database. The advantages of this include the following:

• Having full control over the database and its security

• Fast retrieval of user information

• The ability of users to connect from any computer and still use our web application in the same manner

As we saw in Chapter 9, "Designing and Creating Your Database," the process of designing and normalizing our database is likely to leave us with a dedicated table for our users.

What to Store and What Not to Store

Once we have decided to place user information in a database table, we have to decide what we will store. There are two things to consider: which information to store, and whether a particular piece of information is mandatory.

When we are designing our E-Commerce application, we will inevitably ask ourselves what information we would like to obtain from a user. The following list is a reasonable first guess:

• Username(*) (convenient login name)

• Password(*)

• Full name(*)

• Company name

• Address(*)

• City(*)

• Province/state(*)

• Zip/postal code(*)

• Country(*)

• Phone number(*)

• Credit card information(*)

• Date of birth

• Gender

In the preceding list, we have marked all the items that are necessary for selling the user something and correctly shipping it to him (ignoring the possibility of a different billing/shipping address) with an asterisk (*). The rest of the information is merely data we might find useful later on. We might use these to take a more analytical look at our customers, but they are not necessary for a purchase.

In addition to the data we obtain from the user, there might be other pieces of information generated by our application that we might store. If we have a rewards system for purchases and offer users "points" or coupons, we want to store these somewhere. Similarly, some sites have the concept of a "wish list" or "favorites" list, where users can go back and browse things they want but have not yet purchased.

Very Sensitive Data

The one item in the preceding list of information that deserves a second look is the credit card number. This is a powerful piece of information which, in the wrong hands, can cause a lot of damage to the customer and our reputation with financial institutions. Many major security breaches in web applications involve databases being attacked and compromised. Whenever we have such knowledge about our user, we should ask whether this is something we want to store in the database with the user account, or if this is something we should ask the user about each time he checks out.

Although some users might prefer the convenience of not having to reenter this information every time (they tend to be long strings of digits that take a few tries to get right), many of our users might feel more secure knowing it is not sitting on a server somewhere. We will look at the issue of security and protection for our users in greater detail in the next chapter and in Chapter 20.

Passwords

While passwords are strings, we should be careful about storing passwords in our databases as plain text. If our database server were ever compromised, the person or persons doing so would find themselves with the ability to masquerade as any user in our system without our knowledge.

It is better to encrypt the passwords before putting them in the database by using a function that returns the encrypted password in a plain text format, such as PHP's crypt or md5 function. To verify a user's identity, all you must do is run the crypt (or md5) function on the password he supplies and make sure that the resulting value is the same as that stored in the database.

This has the advantage of making sure the passwords can never be discovered, even by our system administrators or the people who compromise our systems. While other data would still be exposed and compromised, users' passwords would remain secure.

However, this has the disadvantage of making sure the passwords can never be discovered, even by our system administrators! If a user forgets his password, there is no way to tell him what it isthe best we can do is create a new one for him and let him change it on his own. In this case, we will want to be sure that the user saying he has lost his password truly is the user he claims to be.