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.

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.

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.

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).

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.

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.

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!

Your latest PHP/MySQL website is finally online. And it's awesome. But it's not as fast as you want it to be, because of the many SQL queries running every time a page is generated. And above that, you have the feeling it will not scale well under heavy loads. And you are most likely right. In this tutorial, we will see how you can greatly improve your website's responsiveness [...] by implementing a cache layer between your code and your database. The good news is it is fairly easy, and can be done in a few minutes!

They help you get the memcached server installed (a one-liner in most linux distributions) and how to install the memcached extension using PECL. Code is included showing you how to connect to the server, store data into the cache based on a generated key and how to pull the same data back out.

Programming contracts are tests around functions and methods, and they are normally used: to catch any 'bad' data that has been passed into the function or method from the caller, and to catch any 'bad' data generated by the function or method before it can be returned to the caller. These are pre-condition and post-condition tests, and they are tests that either pass or fail.

He points out that by having contracts you not only increase the robustness of your code but you also save time not trying to hunt down data-related issues. Using pre-conditions, you can can check data to ensure things like correct formatting, data that's out of range and data that might be missing. His ContractLib comes with a set of tests that provide good examples of how to use the functionality. Installation instructions are included.

In this two-part tutorial, I show why the use of static helper classes can be detrimental to building robust and scalable object-oriented applications in PHP (though you should take into account that the concept is language agnostic). I also implement a set of instantiable, fine-grained validators, which can be easily tested in isolation, injected into the internals of other objects, and so forth.

Their set of "concrete validators" are all based off of a validator interface/abstract class and check things like email formatting, floats, integers and URLs. Also included are a few examples of using the validators in a sample script.