In this recent post to Reddit.com, the question of application security is asked - the poster wants recommendations on how he should keep his app safe from would-be attackers:

I can code fairly well in PHP these days, but my security isn't so hot. Is there a tutorial or plugin you guys can recommend as to how I should be protecting my php pages/inputs? I want to avoid common attacks like XSS, inputs with NULL or DROP TABLE etc?

Responses on the post include recommendations related to:

• Using the Chorizo scanner to find common issues in your code
• Using PDO for database connections (with bound parameters)
• Not trusting "$_SERVER"
• Data sanitization

There's also links to a few other resources with more details.

PHPMaster.com has a new tutorial posted today (by George Fekete) about preventing cross-site scripting attacks in your PHP-based applications.

Unfortunately, cross-site scripting attacks occurs mostly, because developers are failing to deliver secure code. Every PHP programmer has the responsibility to understand how attacks can be carried out against their PHP scripts to exploit possible security vulnerabilities. Reading this article, you'll find out more about cross-site scripting attacks and how to prevent them in your code.

Included in the tutorial is an example with a simple form and definitions of different types of XSS attacks - reflected XSS, persistent XSS and three ways to prevent them: data filtering, output filtering and data validation. He also links to a few "cheatsheets" to help even more (including this guide and a Zend Framework set of XSS test data.

Kevin Schroeder has posted the second part of his ZF2 dependency injection series (part one here) talking about their configuration.

In my previous post about Dependency Injection Container (DiC) configuration I made mention of some more complicated scenarios that you can use to configure your objects. Not that you need help to make it more complicated. [...] That's why I think this series of blog posts are good. They show you how to get started small which is really the only way to get started if you aren't intimately familiar with a DiC.

He expands on the previous example by adding another method that lets you set up some testing data (injected into the Test class object) and feed in the data via the "parameters" DI container configuration.

With a reminder about the best practice of always validating your data, Seth May has this new post about the "Five Ws" of validation - why, when, where and who.

As web developers, the applications you write are complex data processing engines. They try and convince your users to enter good, meaningful data and to respond in solid, predictable ways based on what was entered. Robust data validation will allow the rest of you application to work effectively. [...] Data is scrutinized in various ways to make sure that it adheres to basic restrictions and to fundamental properties. It's no good receiving a sandwich when you expect a car.

The questions he answers are:

• Why is Data Validation Important?
• Where Should I be Validating Data?
• When Should My Data Be Validated?
• Who is Responsible for Validation?
• How Do I Validate My Data? (yes, there's a "w" in there!)

In the real world data is ugly, crazy, and untrustworthy. Your only hope to taming the data beast is to diligently, methodically validate your data.

In this new post to his blog Joshua Thijssen describes something that can help when processing large amounts of data (like, in his example, the text of a book) to search through the information and find if a certain piece of data is in the set - a bloom filter.

Most of my co-workers never really heard of bloom filters, and I'm continuously need to explain what they are, what their purpose is and why it's a better solution than other ones. So let's do an introduction on bloom filters. [...] Bloom filters have the property of being exceptionally fast AND exceptionally small compared to other structures but it comes with a price: it MIGHT be possible that our bloom filter thinks that an element is inside our set, when it really isn't. Luckily, the reverse is not possible: when a bloom filter says something is NOT in the set, you are 100% sure that it isn't part of the set.

He explains how the filter works, noting how it's better for memory consumption and how it's possible for it to give a "maybe" response instead of ab absolute "yes" or "no". He also points out a PHP extension, bloomy that takes the hard work out of it for you.

In a new post to his blog Rob Allen shows how you can return JSON data directly back from a controller in a Zend Framework 2 application.

The new view layer in Zend Framework 2 can be set up to return JSON rather than rendered HTML relatively easily. [...] Firstly we need to set up the view's JsonStrategy to check to a situation when returning JSON is required and then to render out JSON for us.

This "JsonStrategy" does some of the hard work for you - detecting when the client is requesting a JSON response and looking at the data coming into the view to see if it's JSON. He shows how to implement it in a sample module using the "onBootstrap" module and how to force a return of the JsonModel even when JSON isn't requested (useful for a consistent interface).

On NetTuts.com there's a new tutorial showing how you can create Instagram-like filters in PHP using the ImageMagick library/extension.

PHP comes bundled with GD (GIF Draw/Graphics Draw), which is a library for the dynamic creation of images. It can be used for simpler image operation, such as resizing, cropping, adding watermarks, creating thumbnails (Jeffrey wrote about it), applying basic photo filters - you've probably used it before. Unfortunately, if you want to create something more complex with GD, like Instagram effects, you can't. Luckily, though, we have ImageMagick!

He starts off by comparing the two graphics libraries and talks briefly about how to downliad and install Imagemagick on your development platform. Included is a PHP class to help you use it, coming complete with functions for changing the color tone of the image, adding a border and adding a vignette to the image. Also included are some "presets" represented in a few simple functions:

• Gotham
• Toaster
• Nashville
• Lomo
• Kelvin

There's also a few links to other resources you can use to find out more details on what Imagemagick has to offer.

In this previous post PHPMaster.com introduced you to the concept of "domain models", structures defining how data should be formatted for consistency. In this second part of the series, Alejandro show show to integrate them with a data access layer (DAL) to make them easier to work with.

The phrase may sound like an cheap cliché, I know, but I'm not particularly interested in reinventing the wheel each time I tackle a software problem (unless I need a nicer and faster wheel, of course). In this case, the situation does warrant some additional effort considering we'll be trying to connect a batch of mapping classes to a blog's domain model. Given the magnitude of the endeavor, the idea is to set up from scratch a basic Data Access Layer (DAL) so that domain objects can easily be persisted in a MySQL database, and in turn, retrieved on request through some generic finders.

He includes all the code you'll need to create a (namespaced) database adapter (PDO), the mapping layer to tie the domain models together and using it all in a practical "blog" example with posts, comments and users.

In his most recent post Brandon Savage looks at a practice that's becoming more and more common - using a REST API as a data source for a web-based application.

We were faced with an increasing number of data sources, including the coming addition of Elastic Search to the data storage system, and maintenance was becoming a problem. Thus, the decision was made to move our data layer to our REST API exclusively, removing all direct access to data storage from the web interface. This is the second such project I've been on where an external API has been used for the retrieval of all data in an application. It's a novel concept, but one that takes some getting used to to be sure.

He talks about some of the advantages of this approach including the ability to be more flexible with the actual technology used to create the API, the ability to write other applications on top of it and a glimpse into some of the process that's been going on as a part of the project.

Michael Nitchinger has a new post to his blog about a rewrite for the Lithium framework - changing up the li3_fixtures plugin to make it a bit more of what the community needs.

The li3_fixtures plugin was my first Lithium plugin ever, and while it works okay, I feel there is a lot I can do to make it better and more flexible. In this post I want to share my ideas for a new fixture plugin and also want to gather feedback from the community to make it even more awesome.

He gives three instance where fixtures can come in extremely useful - making effective model unit tests with predictable data, mocking models with shortcuts to the data and mocking out web services. Want to add in your own suggestions for his refactor? Comment on the post!