Clic!Dev, ‘Tate, and many more projects!

JSON, or JavaScript Object Notation, is fairly popular.
This is just my modest take on a ‘PHP Object Notation’ implementation.
Note that it is meant to follow how your mind works rather than being syntactically correct; therefore, associative arrays are used in a loose manner where you have to worry about associative syntax as little as possible.
Basically, type away until your object is fully described.

Here is a notation sample:

array(
        'root level' => array(
                'sublevel 1' => array(
                        'sublevel 2' => 'sublevel 3',
                ),
        )
);

.
This syntax can then be used the same way JSON is used, using eval. Here is how and you will immediately notice how the eval() syntax has to differ from the JavaScript one:

$remote_str = << array(
                ’sublevel 1′ => array(
                        ’sublevel 2′ => ’sublevel 3′,
                ),
        )
);
EOB;
// …
eval(’$local_str=’.$remote_str.’;');

.
Feels a bit clumsy. Fortunately, starting with PHP4, if you are not too sad about introducing a statement in your remote string, you can rewrite it like this:

$remote_str = << array(
                ’sublevel 1′ => array(
                        ’sublevel 2′ => ’sublevel 3′,
                ),
        )
);
EOB;
// …
$local_str = eval($remote_str);

.
Better, isn’t it?

In this last listing, you will find the very simple code I wrote to traverse the object. Note that I invoke a callback for every element, otherwise this code would not be very helpful.

Note that this is just a concept for something I needed to throw together quickly therefore there are some limitations; for instance, you cannot have numeric keys since in this context their “keyness” is ignored and even feared.

$children)
        {
                if(!is_numeric($level))
                {
                        $my_uid = $callback($level, $padding, $uid);
                        traverse_tree($callback, $children, $curdepth + 2, $my_uid);
                }
                else
                {
                        $callback($children, $padding, $uid);
                }
        }
}

function do_something($name, $padding, $uid)
{
        $iid = 0; // Bogus value
        print $padding.$name." ($iid)n";
        return $iid;
}

// ———————————————————–
// Here we go
// ———————————————————–
if(count($argv) != 2)
        die("nSyntax: ".$PHP_SELF." ‘root_node_name’nn");
$rootnodename = &$argv[1];

$INS = array(
        $rootnodename => array(
                ‘Bikes’ => array(
                        ‘Yamaha’ => ‘Fz’,
                        ‘Honda’,
                        ‘Norton’
                        ),
                ‘Trikes’,
                ‘Cars’ => array(
                        ‘Chevrolet’ => array(
                                ‘Corvette’ => array(’Z06′, ‘Convertible’, ‘Coupe’),
                                ‘Camaro’,
                                ‘Jimmy’
                                ),
                        ‘Ford’ => array(
                                ‘Mustang’ => array(’GT’, ‘Premium’, ‘Shelby’, ‘Other’=>’Roush’),
                                ‘Explorer’,
                                ‘Crown Victoria’
                                ),
                        ‘Chrysler’ => array(
                                ‘Dodge’ => ‘Charger’,
                                ‘300X’,
                                ‘Le Baron’
                                ),
                        )
        )
);

traverse_tree(do_something, $INS, 0, 1);

print "DONEnn";
?>

.
Invoke with:

php my_php_script.php "Vehicles"

.
“What is this $iid variable?” you may ask.
You will notice that this piece of code is particularly convenient if you want to add a whole tree structure to your database. Say the you are using MySQL and want to create categories and sub-categories, using the column ‘pid’ as a category’s parent id. You would rewrite do_something:

function do_something($name, $padding, $uid)
{
        mysql_query("INSERT INTO my_cat_table(pid, title) VALUES({$uid}, '{$name}')");
        $iid = mysql_insert_id();
        print $padding.$name." ($iid)n";
        return $iid;
}

Voila!

Every now and then, a developer makes a post on their blog that, to the unsuspecting novice, seems like common sense.
Beware, though. If the post is less than comprehensive or accurate, it better not be about security matters or that newly acquired peace of mince may be quickly shattered.

Exhibit A: This post on the topic of PHP and SQL injections. It’s not like there is a lack of information already freely available on the web.
The author even references this excellent material at the end of his post. It is too bad that his own article actually contains less relevant information than the original post.

For instance, he recommends the use of mysql_real_escape_string().

• Observation #1: this implies that you are using mysql as your database of choice. Granted you may use this method before sending a SQL query to Postgresql, but then there is no guarantee that mysql functions were compiled in the current php library.
• Observation #2: mysql_real_escape_string() does nothing more than escape quotes. From the original article: “Be aware that “sanitizing the input” doesn’t mean merely “remove the quotes”, because even “regular” characters can be troublesome.“

He recommends validating for the proper input, which is good practice. So, brownie points for that. But it wouldn’t hurt to have, for instance, mentioned the use of intval() to enforce that integer values are nothing but that. Integer values. I would say that it’s advice just as important as escaping input strings.

Now, the part that I found horrifying, but it’s just me, I’m a stickler: the author encourages you to code your HTML forms so that they will not accept too many characters. I see here some confusion: this is good usability advice, granted, but as far as security it is misguided.

The golden rule is simple: Always perform input validation server-side, where the user cannot ‘fake’ the values they are sending to your application.
Never, ever accept data “as-is” if it came through a path that allowed it to be tampered with.

Two other equally important points I wish he had mentioned are:

• Configure error reporting so that your server does not display these “helpful” error messages that he mentions and attackers are delighted to find
• A good SQL query is one cautiously put together, but a great SQL query relies on prepared statements. There are cases when you are after raw speed and direct queries feel more ‘natural’ -I know, I use them a lot- but whenever possible, use prepared statements, since the user is then not given a chance to “write” your query string himself.