Problems in paradise: Guestbook v2

Even our simple guestbook is problematic to use, for a variety of reasons. Firstly, all fields are optional currently, which means we can get entries like this: "Posted by on 24th of March 2004" - not ideal. Secondly, people can add HTML to their posts freely, and thereby take over our site in any number of ways. Finally, visitors can post all sorts of obscenities on our guestbook, as we make no attempt to filter things out.

So, it is time to reanalyse the guestbook design and have a think about where we can solve these problems. It is relatively simple to have all fields required, using code something like this:

if (!empty($_POST['GuestName']) && !empty($_POST['GuestEmail']) && !empty($_POST['GuestMessage'])) {

Note that empty() does not generate an error if the variable is not set, so this should work fine. It is also possible to have empty variables with replaced with a text value along the lines of "no value provided", e.g.:

if (empty($_POST['GuestName'])) { $GuestName = "Anonymous Coward"; }

As you can see, it is not difficult, so do not spend too much time thinking about it right now. Stripping HTML tags is also simple, thanks to the strip_tags() function, so again do not worry about this. The main problem is the filtering required for messages - as it stands, our visitors can post whatever they want, which may not be appropriate for your site. While it is of course impossible to automatically filter out content based on meaning (racism, sexism, etc), it is certainly easy to filter out content based on words, which means it is easy to match and filter swear words from our guestbook.

Naturally I am not about to list a load of swear words here for the guestbook to ban, as it would hardly be fit to print! So, for the sake of this example, "dog" and "hamster" are the words we will be filtering. Filtering can either be done at the time of submission, or it can be done at the time of display; both have their advantages. The advantage to filtering at submission (removing unsavoury content before it gets into the database) is speed - you only need filter it once. The advantage to filtering at display time (that is, storing content unfiltered and filtering it live each time read.php is loaded) is you always have a copy of the original text - this is helpful if you later amend the words you filter, as it will take effect on all messages immediately.

 

Want to learn PHP 7?

Hacking with PHP has been fully updated for PHP 7, and is now available as a downloadable PDF. Get over 1200 pages of hands-on PHP learning today!

If this was helpful, please take a moment to tell others about Hacking with PHP by tweeting about it!

Next chapter: Fixing the problems >>

Previous chapter: Development

Jump to:

 

Home: Table of Contents

Copyright ©2015 Paul Hudson. Follow me: @twostraws.