831Chapter 44User Authentication$feedback_str$noconfirm$confirm EOPAGE; echo $page; site_footer(); ?> Login/LogoutIf your registration process is well designed in the first place, it can help your login processbe more effective. So, for example, if you strictly enforce e-mail and username uniquenessduring registration, in theory, you do not need to check for those things during login. Youmay still want to as a belt-and-braces kind of thing, but it all depends on how much you trustyour registration. In the case of the registration system in the preceding section, our methodof using a one-way hashing function to encrypt passwords and e-mails can also be adapted toenhance the reliability of cookies in an extremely scalable way. Here s the problem we re trying to solve: After a user logs in, we want to set a cookie thatuniquely identifies the user. Say we set a cookie that contains the user s username on oursite, which is generally not a very private piece of information in fact, it s a method of saving people from having to use their real names in public. A cookie, however, is just a textfile there s literally nothing stopping you from writing up a cookie file on your computerthat claims you are someone else. Sites deal with the cookie-verification problem in different ways, the most common of whichis checking your cookie data against a database on every page load. This is not a very scal- able solution, however, unless you have some kind of serious data-caching mechanism, because eventually the database becomes a bottleneck. The solution that we use is a little bit different. When users log in, we look them up in thedatabase by their usernames and passwords. If we find them in there, we set two cookies peruser: one with the username and one with the hashed product of the username and a super- secret string known only to us. Now on every page load, we check for the existence of thesecookies but also we see if they match and if they were set by us, by hashing the value ofthe username cookie with the super secret string and then comparing it to the hash cookie. All this is done on the Web server at relatively little cost in time or cycles, rather than neces- sitating the opening of a connection to the database. Again, we must trust that the secretstring is not compromised but in the worst-case scenario, we could change this string andmerely cause everyone to be logged out suddenly. After we confirm that the cookies do, in fact, match, we can optionally go even further by set- ting a global logged-in flag. This isn t the most secure method possible, but it s extremely fast. You may consider using a logged-in flag for reads and reserving every-page cookie-verificationfor tools such as adding content or changing passwords. You could do this by splitting theuser_isloggedin()function in Listing 44-4 into two functions: one to detect the flag andone to match up the cookies.
Searching for affordable and proven webhost to host and run your servlet applications? Go to Linux Web Hosting services and you will find it.
