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:
- ISBN is exactly 10 digits (last digit can be an ``X''). Also we verify the check digit
- Condition is a single digit in the range 1 to 4 (4=excellent, 3=good, 2=fair, 1=poor).
- Price is a number in the range 0.0 to 200.0.
- Comments are (optional) free-form text with no more than 300 characters.
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:
- Some CSS formatting to make the form and displayed information look decent.
- Client-side validation that will sit on top of the existing server-side
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:
- If errors are caught by the client the response-time is quicker for the user.
- It can reduce load on the server. Imagine a form in which a user tries to
submit the form unsuccessfully three times. If you are using only server-side
validation there are three posts sent to the server. Each time the server
has to check the page, re-build the form, and send the form to the client
(who then wipes out the previous page and replaces it with the new page
that looks just like the old one except that it has an error message). If using
client-side validation the server only handles the form after the errors
have been fixed.
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:
- What type of encoding you need depends on the context of where you are
placing the untrusted on your page. (If want specifics see
for a good discussion of this point.)
- After you validate some types of data (server-side!) you don't have to
worry about XSS. In this assignment, consider ISBN as an example. The value
for ISBN comes from a form in which the user can type whatever they want
(i.e., untrusted). However, before we do anything with that number we
strip out the dashes and verify it contains exactly 10 digits. After
that validation we are no longer concerned that it might be malicious
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.