Blesta 3 offers a huge collection of programming tools for developers. From encryption to session handling, and everything in between. Today we’ll focus on the ins and outs of input validation using the Input component packaged with minPHP.

Input validation in version 3 is clear, concise, and modular. Rules reside within the business logic (the model). The benefit of this design is three fold:

1. No (or at least reduced) redundancy
2. Increased readability/writability
3. Reduced testing/less bugs

Some may argue the benefits of input validation from the first source (i.e. the controller). The folly of this design is its complexity and redundancy. Suppose a client can sign up through an order form, through a signup form, or be created by a staff member. Now you have three locations to test, update, and debug each time a business rule changes (for example, phone number is now required). Now suppose you need clients to be created through an API. Adding a fourth set of rules is just plain silly. A client is a client, regardless of where they originate, so why not consolidate all of this?

“Well, Cody,” you might say, “a phone number is only required when a client places an order so we need separate rules.” Hogwash! Add a parameter to your Clients::add() method to identify a signup via order to set the phone number rule as required.

Let’s look at a few examples.

<?php 
// /app/models/clients.php
class Clients extends AppModel {
    public function __construct() {
        Loader::loadComponents($this, array("Input"));
    }
 
    public function add(array $input) {
        // Input is coming straight from POST
        $rules = array(
            'first_name' =--> array(
                'empty' => array(
                    'rule' => "isEmpty",
                    'negate' => true,
                    'message' => $this->_("Clients.!error.first_name.empty"),
                    'post_format' => "trim"
                )
            ),
            'last_name' => array(
                'empty' => array(
                    'rule' => "isEmpty",
                    'negate' => true,
                    'message' => $this->_("Clients.!error.last_name.empty"),
                    'post_format' => "trim"
                )
            ),
            'email' => array(
                'format' => array(
                    'rule' => "isEmail",
                    'message' => $this->_("Client.!error.email.format"),
                    'post_format' => "trim"
                )
            )
        );
 
        $this->Input->setRules($rules);
        if ($this->Input->validates($input)) {
            // Insert into the database, email, or do anything else needed when a client is added
        }
    }
}
?>

Let’s break this down.

1. Line 5 loads the Input component (in reality this is already done in AppModel, but you ought to know how it happens)
2. Lines 10 – 34 define our rules. For those who’ve worked with cakePHP this will look somewhat familiar.
3. Lines 11, 19, and 27 are the indexes of the input data from our input array parameter. Evaluating arrays would look something like ‘addresses[]’, or ‘addresses[][city]‘, etc.
4. Lines 12, 20, and 28 begin individual rule sets. The labels here are superfluous (we could use numerically indexed elements instead), but these help us understand what’s expected of the rule. Any number of rule sets can be added.
5. Each rule contains two necessary components:
   1. The ‘rule’ index, and
   2. The ‘message’ index
6. The first defines how the input is evaluated. If the rule returns true the validation passes, if false, the validation fails. The message is what’s set for the error upon failure. In this example, and throughout Blesta, messages are language definitions which are translated before being set ($this->() maps to [Language::()]3).
7. Lines 14 and 22 tell the “isEmpty” rule to negate the response. Obviously we don’t want to require first and last names to be empty. Instead we want to ensure non-emptiness.
8. Lines 16, 24, and 31 perform a formatting action on data after the rule is evaluated. Conversely, there’s a ‘pre_format’ action that formats the data before the rule is evaluated. Both ‘pre_action’ and ‘post_action’ work just like ‘rule’.
9. Line 36 prepares the rules for evaluation
10. Line 37 runs the validation, setting any errors that are encountered into the Input object, accessed via Input::errors(). AppModel defines a public method called “errors” to grant access to these errors from our controllers. As you’ve probably deduced, Input::validates() returns boolean true if validation was a success and false otherwise.

In the above example, all of the rules are defined within the Input component, but rules can consist of PHP functions (as seen on line 16), callbacks, or even boolean values. In addition, a rule can also define parameters. In any case, however, the first parameter to the rule is always the input value.

Below we look at an example of a rule set where the phone number is conditionally dependent on a method parameter, with a more complex rule.

<?php
    if ($order_signup) {
        $rules['phone'] = array(
            'format' => array(
                'rule' => array(array($this, "isPhone"), $input['country']),
                'if_set' => true,
                'message' => $this->_("Client.!error.phone.format"),
                'final' => true
            )
        );
    }
?>

Notice we now have a couple new actions. The ‘if_set’ action allows the rule to be executed if and only if the field is set. The ‘final’ action tells us that if this rule does not pass evaluation then there’s no point in evaluating any other rules. Similarly, there’s another action called ‘last’ that will cease evaluating rules within a particular rule set (that is, for a single field).

Our rule is to execute a public class method and pass an additional parameter which will help us determine the correct format for the phone number based on the country. The signature of Clients::isPhone would look something like this:

public function isPhone($number, $country)

As you’ve seen, the Input component allows us to reuse code (one of the main goals behind object oriented programming), reduce redundancy, and create readable rules quickly and easily.

Browsers have come a long way in preventing malicious scripts from compromising a user’s system, but XSS (Cross Site Scripting) still poses a security threat for developers. In version 3, we make use of a couple libraries packaged with the minPHP framework and recommend you do the same with your plugins, modules, or gateways. They are the Html and Formhelpers.

In the previous article I showed how to eliminate SQL inection, but what do you do when a user submits some XSS code through a web form? Obviously parameter binding won’t help you there, so what do you do? Nothing. Well, at least for now, and here’s why:

1. Sanitizing input for XSS is expensive (both computationally, and economically). Web technologies change very frequently. What if W3C decides to add an “ontrippleclick” event?
2. Not all form data will end up in an HTML document. Some data is destined for emails or 3rd party APIs.
3. Sanitizing may make the data less or unsearchable by the database engine.

So when do we deal with this potentially hazardous data? Why, when we render it of course. And here’s how that’s done:

<div>Name: <?php $this->Html->_($name);?></div>

In the above example, Html::_() both sanitizes and prints the data, but we can force it to return the sanitized output by setting the 2nd parameter to false. Neat-o. When used in a form, the Form helper will take care of drawing the form field and sanitizing the data.

<div>Name: <?php echo $this->Form->fieldText($name);?></div>

One thing to note is that we’re not destroying the XSS, we’re simply treating it as plain-text within an HTML document. While this takes care of most scenarios, there are some instances the Html helper can’t help you with. One such case is in dealing with the href attribute of an anchor tag. As a programmer you simply need to be aware of such pitfalls and address them accordingly.