Tomas Votruba has continued his series covering the use of the Symfony Console component with a new tutorial. In this latest article he shows how to get "stylish and standard console output" using the output formatting included with the package.

Even if you don't use any component from Symfony or even installed one, you can use this trick in your PHP CLI App.

It's simple, provides standard and makes your output look like a design from Apple - useful and nice at the same time.

He starts by introducing the OutputInterface that the Symfony Console package includes and shows a few screenshots of the difference between normal console output and the Console component's look. He also covers the SymfonyStyle functionality that allows for even more fine-grained control over the input and output handling of your application. He finishes the post showing a few tips on integrating these styles into your command line application and setting it up to fetch SymfonyStyle as a service.

Aaron Saray has a post to his site sharing the "anatomy of a PHP hack" - the evidence that he found and pulled apart based on a recent hack he experienced.

It’s hard to come up with a title for this - but - basically I found some rogue code the other day that I thought was pretty interesting. I was fixing a “hacked” website when I came across the source of the symptoms of the hack.

He starts with the code he found in the hacked website, obfuscated to hide the true intent and how he disassembled it to find the true intent. He walks through the method he used to reverse the code ultimately ending up with a simple call to base64_decode a value that comes in from a $_POST request.

Matthew Weier O'Phinney is back on the Zend Framework blog today with a spotlight on another component of the Zend Framework. This time he features zend-inputfilter, a useful component for filtering the data coming into your application from your users.

In our previous two posts, we covered zend-filter and zend-validator. With these two components, you now have the tools necessary to ensure any given user input is valid, fulfilling the first half of the "filter input, escape output" mantra.

[...] To solve [the single shot validation] problem, Zend Framework provides zend-inputfilter. An input filter aggregates one or more inputs, any one of which may also be another input filter, allowing you to validate complex, multi-set, and nested set values.

As in the other tutorials in the series, Matthew walks you through the installation of the component via Composer and briefly describes how it operates. He then includes a code example of creating a new InputFilter instance, making inputs, attaching validators to them and then ensuring everything validates in the chain with an isValid call. He then covers input specifications - configurations based on array values - to define validators on the input elements. He ends the post looking at input filters, how to manage them and defining them by specification. He also mentions a few other pieces fo functionality the component includes but he didn't cover here.

The Zend Framework blog has posted a new tutorial covering a single component of the framework. In this latest article ZF lead developer Matthew Weier O'Phinney covers the zend-filter component for filtering input from your users.

When securing your website, the mantra is "Filter input, escape output." We previously covered escaping output with our post on zend-escaper. We're now going to turn to filtering input.

Filtering input is rather complex and spans a number of practices: filtering/normalizing input [and] validating input. For now, we're going to look at the first item, filtering and normalizing input, using the component zend-filter.

He shows you how to get the component installed, via Composer, and talks about some of the dependencies it needs, optional and required. Since they'll be using the "FilterChain" functionality, he also requires that. He moves into the code, showing the interface required for a validator to work (basically just defining a "filter" method). He talks about some of the common filtered included and how to refactor custom validation handling into a FilterChain performing the same operations. He ends with another example of reading from a file and how to use it on an array of values, each line as a string from the file.

In a post to his site Sebastian de Deyne makes the suggestion that you should normalize your values (input) as soon as possible.

Dynamic languages allow us to pass anything as a parameter without requiring a specific type. In turn, this means we often need to handle some extra validation for the data that comes in to our objects.

This is a lightweight post on handling your incoming values effectively by normalizing them as soon as possible. It's a simple guideline worth keeping in mind which will help you keep your code easier to reason about.

He gives an example of a HtmlClass object instance that can take in either a single string or an array of strings. With this structure he shows the complexity it would add for methods like toArray and toString. Instead he recommends normalizing the value in the constructor, making it an array if it's not already. The the code required in the rest of the class to use/translate it is much simpler.

The SitePoint PHP blog has posted a tutorial continuing on from some previous advice with even more defensive programming practices you can use in your PHP applications.

Many people argue against defensive programming, but this is often because of the types of methods they have seen espoused by some as defensive programming. Defensive programming should not be viewed as a way to avoid test driven development or as a way to simply compensate for failures and move on. [...] What are these methods, if not ways to anticipate that your program may fail, and either prevent those, or else ways in which to handle those failures appropriately?

They go on to talk about the ideas of "failing fast" when errors happen in your application with an extra suggestion added on - "fail loud" too. The tutorial then looks at four different places where more defensive programming techniques can be applied (and how):

• Input validation
• Preventing Accidental Assignment in Comparisons
• Dealing with Try/Catch and Exceptions
• Transactions

They end with a recommendation that, while you should fail fast and loud when issues come up, be sure it's not to the determent of the overall user experience or sharing messages with users that may just confuse them.

In his latest post Derick Rethans shares his answer to a question he was asked at a recent PHP conference regarding the escaping of input before use in a MongoDB query.

At last weekend's PHP Benelux I gave a tutorial titled "From SQL to NoSQL". Large parts of the tutorial covered using MongoDB—how to use it from PHP, schema design, etc. I ran a little short of time, and since then I've been getting some questions. One of them being: "Should I escape my input, and if so, how?". Instead of trying to cram my answer in 140 characters on Twitter, I thought it'd be wise to reply with this blog post. The short answer is: yes, you do need to escape.

He uses the rest of the post to get into the longer answer, a bit more detail about why you should escape and what kinds of things can be done. He points out that, because of how MongoDB queries are created, SQL injection is much more difficult. He does remind you that superglobals can also be used to send arrays too which could lead to unexpected data input. He gives an example of how this would work and why it would be a problem.

So although MongoDB's query language does not require you to build strings, and hence "escape" input, it is required that you either make sure that the data is of the correct data type.

Hari KT has a new post to his site today showing how you can integrate the Aura PHP components into a Slim framework application for input handling, like from a form. Aura PHP is a set of decoupled components for things like CLI handling, dependency injection and SQL requests (among others).

Rob Allen wrote about Integrating ZF2 forms into Slim. I did write how you can use Aura.Input and Aura.Html to create standalone form for PHP. This time I felt I should write about integrating aura input inside Slim.

He includes the Composer configuration to install the HTML and Input components as well as an up-to-date version of the Slim framework. Code showing how to create the form class (a "Contact form") is included, showing both the creation of the elements and the filtering/validation checks put on each. He shows how the Slim routes would handle the request as well as how the view processes the request and displays the form via a helper. You can get the full working code in this repository over on GitHub.

Greg Freeman has a post today looking at using streams and STDIN in PHP to handling incoming data (like to a CLI script).

PHP streams are still lacking in documentation and are rarely used compared to other PHP features. This is a shame because they can be really powerful and I have used them to gain a lot of performance when doing things such as processing log files. One of the more powerful features of Linux is the ability to pipe in data from another program, it’s often faster to offload tasks to an existing linux user space program than to do it in PHP and the added benefit is that you gain multi core processing which is not possible with standard PHP.

He talks briefly about the "pipe" character and how it allows you to send the output from one command to another. He shows how to mimic this same kind of input handling in PHP using the "php://stdin" stream and a fopen function call. He gets a bit more in-depth into how the streams work (blocking) and a bit of configuration and data you can get about the current streams. The post finishes with an example of a non-blocking input handler that will automatically end execution if no data is given within three seconds.

As Paul Jones mentions in his most recent post (pulled from the Aura blog), the Aura framework has some new releases of its component packages - specifically Input, Sql and View.

On the heels of last week’s slew of releases, we have three followups! The Aura.Input package got a feature-level bump to 1.1.0, with a new FormFactory. Thanks to Hari KT for championing that one. Aura.Sql is now at 1.3.0, due to lots of work from MAXakaWIZARD to provide SQLite- and PostgreSQL-specific query objects. Finally, the Aura.View package got a bugfix and is now at 1.2.1; it handles content-type negotiation better for those times when there is no Accept header.

If you'd like more information about the Aura framework, check out the project site or each of the packages that make it up. Aura is a decoupled set of components without additional dependencies.