Handling input with the Zend Framework (Post,get,etc)

Question

im re-factoring php on zend code and all the code is full of $_GET[\"this\"] and $_POST[\"that\"]. I have always used the more phpish $this->_

Answer 1

I have always used the more phpish $this->_request->getPost('this') and $this->_request->getQuery('that') (this one being not so much logical with the getquery insteado of getGet).

What is best of this two? (or if theres another better way)

Just a quick explanation on the choice of getQuery(). The wording choice comes from what kind of data it is, not how it got there. GET and POST are just request methods, carrying all sorts of information, including, in the case of a POST request, a section known as "post data". A GET request has no such block, any variable data it carries is part of the query string of the url (the part after the ?).

So, while getPost() gets the data from the post data section of a POST request, getQuery() retrieves data from the query string of either a GET or POST request (as well as other HTTP Request methods).

(Note that GET Requests should not be used for anything that might produce a side effect, like altering a DB row)

So, in answer to your first question, use the getPost() and getQuery() methods, this way, you can be sure of where the data source (if you don't care, getParams() also works, but may include additional data).

What is the best practice for validating php input with this methods?

The best place to validate input is where you first use it. That is to say, when you pull it from getParams(), getPost(), or getQuery(). This way, your data is always correct for where you need it, and if you pass it off, you know it is safe. Keep in mind, if you pass it to another Controller (or Controller Action), you should probably check it again there, just to be safe. How you do this depends on your application, but it still needs to be checked.

Answer 2

I usually use $this->_request->getParams(); to retrieve either the post or the URL parameters. Then I use the Zend_Filter_Input to do validation and filtering. The getParams() does not do validation.

Using the Zend_Filter_Input you can do application level validation, using the Zend Validators (or you can write your own too). For example, you can make sure the 'months' field is a number:

$data = $this->_request->getParams();

$validators = array(
    'month'   => 'Digits',
);

$input = new Zend_Filter_Input($filters, $validators, $data);

Answer 3

not directly related to the topic, but to insure that you get an number in your input, one could also use $var+0 (however if $var is a float it stays a float) you may use in most cases $id = $this->_request->getQuery('id')+0;

Answer 4

$dataGet  = $this->getRequest()->getParam('id',null);
$valid = new Zend_Validate_Digits();

if( isset($dataGet) && $valid->isValid($dataGet) ){
 // do some...
} else{
  // not set
}

Answer 5

Extending Brian's answer.

As you noted you can also check out $this->_request->getPost() and $this->_request->getQuery(). If you generalize on getParams(), it's sort of like using the $_REQUEST superglobal and I don't think that's acceptable in terms of security.

Additional to Zend_Filter, you may also use simple PHP to cast the required.

E.g.:

$id = (int) $this->_request->getQuery('id');

For other values, it gets more complicated, so make sure to e.g. quote in your DB queries (Zend_Db, see quoting identifiers, $db->quoteIdentifier()) and in views use $this->escape($var); to escape content.

Answer 6

You can't write a one-size-fits-all validation function for get/post data. As in some cases you require a field to be a integer and in others a date for instance. That's why there is no input validation in the zend framework.

You will have to write the validation code at the place where you need it. You can of course write some helper methods, but you can't expect the getPost() to validate something for you all by itself...

And it isn't even getPost/getQuery's place to validate anything, it's job is to get you the data you wan't, what happens to it from there on should not be it's concern.