Form Handling due Mon 29 Jan 11:00

\begin{purpose}
In completing this assignment you will:
\begin{itemize}
\ite...
...-side and server-side validation on a single page.
\end{itemize}
\end{purpose}

Overview

At the end of this assignment you will have a reasonably good looking self-posting form that will allow entry of an ISBN, the condition of the book, the asking price of the book, and a comment from the seller. If all goes well you will look up the title, authors, and publisher of the book, year of publication and display on the page (nicely formatted) all the information the user entered together with the title, authors, publisher, and year.

You will sanitize the ISBN by removing dashes. You will validate (on the server-side) form entries as follows:

If something is not valid then display an error message under the offending entry. You will properly encode (to avoid XSS issues) all untrusted data being displayed to the screen.

After all these features are present and working you will add:

Why Use Client-Side Validation?

We have already established that client-side validation is no validation at all. For that reason you will ALWAYS perform server-side validation. Also, some types of validation are impossible on the client-side. For example, although we can check that the form of an ISBN is valid and that its check digit is valid that does not guarantee that a book exists with the given number. The only way to know that is to look it up (which is a server-side action)!

Having said that, there are some reasons to do client-side validation:

About XSS and Untrusted Sources

In web programming, for the most part, we distrust anything that we didn't create. This most definitely applies to anything we get from a user. To encode untrusted data that will are going to display on the web page. In this assignment we will use:

htmlspecialchars($input, ENT_QUOTES, 'UTF-8')

for that purpose. It is not correct, however, to blindly apply that function to all output for the following reasons:

When we get to data that comes from the call to googleapis.com it might be tempting to think that such data is trusted. Here is an example of why we don't trust that data: What if someone has written a book called <script>document.location="www.example.com";</script>? For that reason we encode a values that come from the external source before we display them on our page.

Quick Links