New on PHPMaster.com there's a tutorial showing you how to use ClamAV support to work as a validation filter in a Zend Framework application. ClamAV is an open source project that helps identify malicious threats like trojeans, viruses and malware.

Ok, so you're pretty comfortable with using the Zend Framework, specifically the use of Forms. Along with that, you have a good working knowledge of how to combine a host of standard validators [...] but what do you do when a situation arises that's outside the scope of the pre-packaged validators and filters? Let's say you want to guard against users uploading files that contain viruses, for example. You would have to write a custom validator that checks the uploads aren't infected.

You'll need to install the ClamAV extension on your loal machine for the feature to work. Once it's there, though, it's as simple as setting up the validator (based on Zend_Validate_Abstract) and calling the "cl_scanfile" method on the uploaded file. Also included is the code for a sample controller with a Zend_Form instance and an upload file field to help prove it's working.

Jake Smith has a new post to his blog today about a feature included in PHP's Standard PHP Library that you might have overlooked - the FilterIterator's callback functionality.

The Filter Iterator is probably my second favorite iterator, next to Directory Iterator. There are many great use cases for the Filter Iterator, and when you do filter the original data is left untouched. A Filter Iterator is really simple to use, create a class that extends FilterIterator and adjust the accept method to meet your criteria. This is great and all, but having the ability to create filter iterators on the fly, ones that won't be used application wide, without having to create a class is even better.

He includes a bit of code defining a FilterCallbackIterator class with a "callback" parameter passed into the constructor (in his case, a closure). Also included is some sample code of it in use - handling an array (well, ArrayIterator) with a simple true/false check on the current array value. You can find out more about this functionality in the PHP manual.

On Reddit.com there's a recent post that asks the question How do YOU sanitize input in your PHP applications?

I am developing some software for my high school using HTML, CSS, MySQL, and most importantly PHP. [...] So I pose this question, what is YOUR favorite way to sanitize input for inserting, updating, or selecting from a database? Also, is there any way you prefer to verify that input is of a certain type, and only of that type ie, if you're expecting an int or a string, how would you make sure you are receiving one?

Answers on the post touch on things like:

• parametrised queries for databases
• filter_var/filter_types
• Sanitized versus "database-safe"
• using PDO
• avoiding the false sense of security things like mysql_escape_string and mysql_real_escape_string

On the DeveloperDrive.com site today, there's a new post with a few reminders for PHP developers out there of things it's easy to forget when writing your applications - some common mistakes to avoid.

Despite the high expectations placed on them at times, developers are human. They were the last time we checked anyways. As humans, we are bound to make mistakes from time to time. And simple, common mistakes often slip past our filters the more comfortable we become with something. [...] But knowing what these common mistakes are and how to avoid them can really help speed up the development process and keep our clients smiling.

His list includes three big ones that, if forgotten, could end up being detrimental to your application (sooner or later) - poor housekeeping/organization of code, forgetting punctuation and forgetting to validate input from users.

On the DeveloperDrive.com site there's a recent post anyone wondering about cross-site scripting should give a read. They introduce you to the basic concept and two things you can do to help prevent them.

This little fable describes the most common vulnerability found in web sites, the Cross Site Scripting (XSS) attack. According to a report from WhiteHat Security 83 percent of websites they tested have had at least one serious vulnerability and 66 percent of all websites with vulnerabilities are susceptible to XSS attacks making it the most common vulnerability web developers face. To fix this, it takes 67 days on average. Tools like WebScarab and Paros Proxy can be used to scan sites for possible vulnerabilities.

They offer two simple pieces of advice that it's all too easy to forget when developing applications - validate all user input to ensure it's what it should be and escape any untrusted output (even sometimes your own!) before pushing it out to the page.

SitePoint's PHPMaster.com site has a new tutorial today from Timothy Boronczky about handling file uploads in PHP. It's a pretty low-level introduction and is perfect for those new to PHP.

What do pictures in an online photo album, email attachments in a web-based mail client, and data files submitted to an online application for batch processing all have in common? They all rely on the ability to upload files across the Internet from the user's web browser. Indeed, uploading files is an important feature of many of the sites and web-based applications we use on a daily basis. In this post, I show you how to add support for file uploads to your site using PHP.

He starts with the changes you might need to make to your php.ini configuration file (for allowing uploads and setting a temporary directory) and a basic "form" tag with the necessary "enctype" setting. The sample form includes a "file" type field that submits the file data to a waiting PHP script on the backend. The script looks for the submit (in the $_FILES superglobal) and, after doing some filtering on the name and content type, moves it to a new directory.

On the Amazium blog Jeroen Keppens has a recent post looking at some of tools available to you when needing to filter input and escape output in your applications. This post specifically covers filtering on command line applications.

When you need data input in a web context, you send a GET/POST request to your script. On the command line, things work differently. In this blog post, we will talk obout input and output in php-cli.

The post is broken up into a few different sections:

• Handling arguments
• File descriptors
• Interactive input
• Resources mentioned in the post

Tools mentioned include everything from getopt and PEAR's' Console_Getopt out to using file descriptors and working with readline.

On the ZendCasts.com site there's a new screencast showing you how to create custom Zend filters with HTMLPurifier, the standards-compliant tool that can remove potential issues from your HTML as well as restructure it to be more along the lines of the W3C specifications.

He shows how to set up the HTMLPurifier tool into your Zend Framework application so you can use it as a filter on your view's output. He sets it up as a new filter, ZC_Filter_HTMLPurifier, and creates the basic filtering interface library to make it work.

You can find out more about using filters in Zend Framework applications in this section of the manual.

Padraic Brady has a new post looking at a cross-site scripting issue he came across when working with CodeIgniter 2.0.2 and some fixes and recommendations he has about correcting the situation.

EllisLabs' news release for CodeIgniter 2.0.2 makes mention of "a small vulnerability". This small vulnerability is mentioned no where else (not even the actual changelog for 2.0.2). In reality, I reported seven distinct vulnerabilities across two classes. These vulnerabilities might allow an attacker to inject arbitrary HTML, CSS or Javascript, i.e. Cross-Site Scripting (XSS) into an application's output.

He gives a list of four recommendations that CodeIgniter 2.0.2 users can take to creating (or updating) their applications including using HTMLPurifier when you need sanitization and ensuring that views and templates from third parties are clear of XSS issues.

On the Zend Developer Zone they've posted the second part of Vikram Vaswani's look at using the Twig templating engine in your PHP applications. In the first part of the series, he introduced the tool and got started with some simple examples. In this second part, he dives in deeper to some of the advanced features.

In this second and concluding segment, I'll look at some of Twig's other features, including such goodies as template inheritance, custom filters and caching. If you enjoyed the first part of this article, keep reading to find out more about what goes on under Twig's hood, and how you can add even more power and flexibility to your templates

He looks at template inheritance, parent blocks/child templates, data filtering, the tool's "compilation cache" and working with native plugins.