Rob Allen has been working with the Zend_Filter component of the Zend Framework and has discovered a few things:

The basic usage of Zend_Filter_Input is [a simple call to Zend_Filter_Input with the filter types and data to filter]. The problem is that the message you get out isn't always written as you would like. Consider the output if the body record is empty. The text isn't exactly what I would want to display to a user. To change it you pass in a messages parameter to the $validators array.

There's a long list of these "messages parameters" and Rob includes them in the post - things like NOT_ALNUM, CHECKSUM, QUOTED_STRING, INVALID_DASH and UNDECIPHERABLE_TLD (37 of them in all).

Rob Allen has been working with the Zend_Filter component of the Zend Framework and has discovered a few things:

The basic usage of Zend_Filter_Input is [a simple call to Zend_Filter_Input with the filter types and data to filter]. The problem is that the message you get out isn't always written as you would like. Consider the output if the body record is empty. The text isn't exactly what I would want to display to a user. To change it you pass in a messages parameter to the $validators array.

There's a long list of these "messages parameters" and Rob includes them in the post - things like NOT_ALNUM, CHECKSUM, QUOTED_STRING, INVALID_DASH and UNDECIPHERABLE_TLD (37 of them in all).

Ed Finkler has an interesting new post on his blog today that looks at what kind of influence the Zend Framework has had on the PHP community's outlook on secure web development.

I posted this rather lengthy argument in the Zend fw-core mailing list after I learned that the Zend_Filter_Input component had been dropped from the Zend Framework. I have used this component extensively in various projects, and had written up a contribution to the Zend DevZone that described using a bootstrap script to block direct access by your developers to the superglobal user input arrays ($_GET, $_POST, $_COOKIE, etc).

He includes the post and talks about things like the good side of PHP's popularity and the bad side (like developers that cannot write secure applications). He targets the Zend Framework as one tool that has made it slightly harder to write secure applications (as of the move from 0.7 to 0.8 because of small things like having to create a filter object to do any filtering).

The key to his complaint is the removal of the Zend_Filter_Input component which, from his perspective, made things easier to secure and made for simpler and cleaner code.

Ed Finkler has an interesting new post on his blog today that looks at what kind of influence the Zend Framework has had on the PHP community's outlook on secure web development.

I posted this rather lengthy argument in the Zend fw-core mailing list after I learned that the Zend_Filter_Input component had been dropped from the Zend Framework. I have used this component extensively in various projects, and had written up a contribution to the Zend DevZone that described using a bootstrap script to block direct access by your developers to the superglobal user input arrays ($_GET, $_POST, $_COOKIE, etc).

He includes the post and talks about things like the good side of PHP's popularity and the bad side (like developers that cannot write secure applications). He targets the Zend Framework as one tool that has made it slightly harder to write secure applications (as of the move from 0.7 to 0.8 because of small things like having to create a filter object to do any filtering).

The key to his complaint is the removal of the Zend_Filter_Input component which, from his perspective, made things easier to secure and made for simpler and cleaner code.