. 42
( 132 .)



Commenting calls for good judgment. You don™t want to comment too much;
you don™t want to comment too little. Our best advice is to take a look at how other
programmers comment their code and to pick a style that you like. We use one
method for the applications in this book; others have different styles.
The PEAR directory of your PHP installation is a great place to look for tips on
good coding style. PEAR stands for PHP Extension and Application Repository. It is
a growing set of scripts that contains a series of best practices for programming
with PHP. The folks working on PEAR are real pros who write terrific code. We rec-
ommend looking through the scripts in that directory to glean some tips on writing
quality code.

In this chapter, we have presented some ways to write clean and organized code.
When you look at your scripts, you should ask yourself a few questions.
Chapter 7: Writing Organized and Readable Code 225

— Are there blocks of code that are common to every page? Maybe those
blocks can be moved into an include.
— Are there chunks of code that I™m writing over and over again? Perhaps
writing a function or class might save time.
— Is the next person who comes to this script going to be able to figure
out what I™ve been doing? If not, make sure that you add enough com-
ments to make things clear.

You need to decide if an object-oriented approach is good for you and the appli-
cation you™re writing. Our advice: make sure you are comfortable writing clean
procedural code before you jump into object-oriented programming.
Part III
Simple Applications
Guestbook 2003, the (Semi-)Bulletproof Guestbook
Chapter 8

Guestbook 2003, the

— Learning the power of Guestbook 2003

— Organizing your code in a reasonable way

— Writing good, reusable functions

IN THIS CHAPTER WE DEVELOP the first of our applications ” a guestbook. Guestbooks
aren™t complex and they aren™t very exciting. However, this application does give
us the chance to introduce some concepts, such as validation, and put many of the
practices discussed earlier in this book to work.
In the introduction of this book we provided some code that could be used for
the most basic guestbook possible. However, using that code for your guestbook is
not a good idea: It™s got all kinds of holes that will allow malicious people out there
to mess with your pages. The ultra-basic guestbook has another problem: Given the
way the code is just dumped into one page, there™s not a line that™s reusable. One of
the main goals of developing any application is to create chunks of reusable code.

Determining the Scope and Goals
of the Application
The easiest way to get yourself into trouble when coming at an application is not to
know exactly what you are trying to achieve. A vital part of the developer™s job is
to figure out exactly what is needed in the application. Usually doing this will
involve extensive discussion with the people for whom the application is being
developed. During these discussions, it is important to think a step ahead and ask
questions that may not have been asked before. What if the scope increases in a
certain way? What if additional but related information needs to be tracked?
230 Part III: Simple Applications

Considering these and similar scenarios will affect the way you design your data-
base and your scripts, and that is why it is best to know the exact scope and goals
of your application. Depending on whom you™re working with, you may want to
get some sketches of pages that need to be developed.
The scope of this application is small and the goals are minimal. The guestbook
stores names, addresses, and the like. (To tell the truth, the purpose of this chapter
is not so much to show you how to write a guestbook as it to show you how to
write good, reusable, organized code for your applications.) In any case, you should
know what Guestbook 2003 looks like before you proceed.

In this chapter we™re not going to take the notion of creating good functions
as far as it can go. In Chapter 9 we present a more extensive set of functions
that we™ll use throughout the rest of the book.

Necessary pages
This guestbook has three basic pages: one for signing, one for viewing, and one for
Figure 8-1 shows the page that gives the user the opportunity to sign the guest-
book. It™s pretty simple, a form with four text fields and one text area field.
Additionally, there are a submit button and a reset button.

Figure 8-1: Page for signing the guestbook
Chapter 8: Guestbook 2003, the (Semi-)Bulletproof Guestbook 231

Next, there must be a way to see who has signed the guestbook. For the sake of
having readable Web pages, we created a standard style, shown in Figure 8-2, in
which only two entries are printed on each page. At the bottom of the page are
navigational elements that indicate whether previous or additional entries exist.
These should be conditional and should disappear appropriately when you are at
the beginning or end of the guestbook.

Figure 8-2: Page for viewing the guestbook

Finally, we need a page that enables us to delete entries we don™t want. The page
in Figure 8-3 seems to do the trick. Access to this page needs to be limited to autho-
rized users: We don™t want any old schmo going in and cleaning out our guestbook.

What do we need to prevent?
The major problem that we need to tackle in the guestbook application is one that
is common to any application with form input: It is possible for vandals to input
nasty code into your forms that will screw up the pages for everyone else who
comes along. If you used the guestbook application in the introduction you could
be in serious trouble. Consider what would happen if someone inserted the follow-
ing code into a text field:

232 Part III: Simple Applications

Figure 8-3: Page for administering the guestbook

The next time the page loaded, the viewer would be greeted with a little treat seen
in Figure 8-4.
If some jerk felt like it, he or she could screw up your page with all sorts of tags,
as follows:

<img src=http://www.britney-spears.fsnet.co.uk/britney4.jpg>

Additionally, this application requires some validation. When the user enters
information, the application is going to see that it makes sense. The application will
check for the following:

— Email addresses should contain an at symbol (@), one or more characters
before the @, and a dot somewhere after the @. Email validation can get
more complex (and will in later chapters).
— URLs should look like URLs, complete with an http:// prefix and at least
one dot.
— Some text must be entered in the name field. There™s little point to a
guestbook entry without a name.
— No email address should appear more than once in the database.

Once the application has checked all of this, the user will need to be made aware
of any errors. Figures 8-5 and 8-6 show how we will indicate these errors.
Chapter 8: Guestbook 2003, the (Semi-)Bulletproof Guestbook 233

Figure 8-4: Results of a problem entry

Figure 8-5: Reporting bad information
234 Part III: Simple Applications

Figure 8-6: Reporting a duplicate entry

Designing the Database
We covered the normalization process in Chapter 1, and before long we™ll put these
normalization skills to work. For this application the set of information is pretty
simple. So simple, in fact, that a single table will do the job. Actually, that isn™t
quite true. For administrative purposes, you should create a table against which
user names and passwords can be authenticated. Here are the create statements
that will make the tables:

drop table if exists guestbook;
create table guestbook
entry_id integer not null auto_increment
, name varchar(40) null
, location varchar(40) null
, email varchar(40) not null
, url varchar(40) null
, comments text null
, created timestamp
, remote_addr varchar(20) null
, primary key (entry_id)
Chapter 8: Guestbook 2003, the (Semi-)Bulletproof Guestbook 235

, unique (email)

drop table if exists guestbook_admin;
create table guestbook_admin
username varchar(50) not null
, password varchar(255) not null
, primary key (username)

When you are adding a user to the guestbook_admin table, it would be best to
encrypt the password. The easiest way to do this is by using a built-in MySQL pass-
word encryption function like sha1(), as follows:

insert into guestbook_admin (username, password)
values (˜jay™, sha1(˜rules™));

After you™ve run this command, the actual value stored in the password column
is caa155adf81fddd29ab4b21a147927fb0295eb53. When you need to find out
whether a user knows the password, you can use the sha1 function again:

select * from guestbook_admin where
username = ˜jay™ and
password = sha1(˜rules™);

From the latest MySQL documentation:“Note: The PASSWORD() function is
used by the authentication system in MySQL Server, you should NOT use it in
your own applications. For that purpose, use MD5() or SHA1() instead. Also
see RFC-2195 for more information about handling passwords and authen-
tication securely in your application.”

Code Overview
In this, the first of your applications, you need to look at the architecture you will
use in constructing your applications. The applications on the CD have been con-
structed so that they are as reusable and portable as possible.
To start with, the CD contains a folder named book, which should be copied to
the document root directory of your Web server. On Apache this folder is usually
named htdocs by default. The book folder contains all the applications documented
in this book.
236 Part III: Simple Applications

Within the book folder is a series of folders, one folder for each of the applica-
tions presented here, one labeled classes, and one labeled functions. For the purpose
of this application we will concern ourselves with the basic.php file in the functions
folder; this file defines some functions that you will use in a variety of applications.
We™ll discuss the functions in basic.php that are used in Guestbook 2003 in the sec-
tion entitled “Code Breakdown.”
The code that is relevant only to Guestbook 2003 is kept in the guestbook2k
folder. Here, startup code that needs to be run at the beginning of each page is run
by the header.php file. The header.php file contains, in turn, two other files: globals.
php and functions.php. This is a structure that we™ll be using through all the exam-
ples in the book. The globals.php file is where you create global variables and
define constants for use in the application. The functions that will need to be
addressed across a number of pages are kept in the functions.php file. We will also
explain these functions in detail in the “Code Breakdown” section.
The pages that are called from the browser are named intuitively: view.php,
sign.php, and edit.php. The other page of the application is confirm_delete.php,
which is called only by edit.php and not by the user directly.
You may find the view.php, sign.php, and edit.php files surprisingly short. They


. 42
( 132 .)