The PHP project has officially released the latest versions in both the 5.3.x and 5.4.x series in response to a bug that was found in the CGI setup of certain server+PHP configurations.

There is a vulnerability in certain CGI-based setups (Apache+mod_php and nginx+php-fpm are not affected) that has gone unnoticed for at least 8 years. Section 7 of the CGI spec states: 'Some systems support a method for supplying a [sic] array of strings to the CGI script. This is only used in the case of an `indexed' query. This is identified by a "GET" or "HEAD" HTTP request with a URL search string not containing any unencoded "=" characters.'

A large number of sites run PHP as either an Apache module through mod_php or using php-fpm under nginx. Neither of these setups are vulnerable to this. Straight shebang-style CGI also does not appear to be vulnerable. If you are using Apache mod_cgi to run PHP you may be vulnerable. To see if you are, just add ?-s to the end of any of your URLs. If you see your source code, you are vulnerable. If your site renders normally, you are not.

You can download this latest version from the downloads page for the source releases or windows.php.net for the Windows binaries. You can look at the Changelog if you'd like more details on the update.

In his previous post Sebastian Göttschkes introduced a set of classes you could use for different types of testing in your Symfony2 applications. In his most recent post he expands on these examples, giving the UnitTestClass an extra ability.

In one of my last articles on Testclasses for symfony2 I explained some of the classes I use for my tests. Since then I found a great article on metatesting and want to update my UnitTest class to show some practical examples.

His update allows the class to access private properties via a "getAttribute" method that, via PHP's Reflection, allows you to pull out the private property's value and a "setAttribute" that lets you inject a value back in. He includes a word of warning, though - if you're using something like this often., you're probably "doing it wrong" and might need to think through your application design a bit more.

You can find the source for his classes in his previous post.

Volker Dusch has a new post reminding us about what the "unit" part of "unit testing" means - small chunks of testable parts in an application.

What does the word UNIT in unit testing stand for? Think of an answer and read on! So? Did you say "A method! Because we test methods!"? If so let me offer another perspective.

He suggests that, rather than about just the methods in the class, it's more about testing the "observable behaviors" of the class. That is, anything that you could publicly use the class for and have something happen. He gives examples of this shift in focus - calling setValue and evaluating the result versus just calling the class property itself (then calling the method). He also includes a bit about testing behaviors - what happens when my script does [this] and how does that effect the overall class.

When your tests fail but the class "still works" and you need to "fix the tests" the your tests are worth a lot less as they don't really give you that cozy safety net that they should provide you with.

On PHPMaster.com today there's a new tutorial posted about using type hinting in your PHP applications to restrict the values passed into your methods.

Since PHP 5 you can use type hinting to specify the expected data type of an argument in a function declaration. When you call the function, PHP will check whether or not the arguments are of the specified type. If not, the run-time will raise an error and execution will be halted.

Included in the post are code examples showing how to define custom types in a function definition and what happens if you pass the wrong type in. Also mentioned is one of the main limitations to hinting - the fact that it can't be used on default PHP variable types.

On the Refulz blog they've posted the next in their series about access control in CakePHP applications. In this new article they look at Access Request Objects (AROs) and Access Control Objects (ACOs) and how they can be managed via the built-in ACL functionality.

Continuing with Access Control Lists, we will read about the two Access Control Lists and their mapping. The Access Request Objects (AROs) are a list of the things that seek permissions and the Access Control Objects (ACOs) are the resources on which permissions are required. Both the lists are maintained in the tow tables, namely aros and acos respectively.

Included in the post is the SQL you'll need to create the tables for the system to use as well as some basic code to use the AclComponent with the ACOs/AROs. They also show how to use the parentNode method to create parent/child relationships between the objects.

Dave Marshall is in the process of building a "RESTish" web service and has shared some of his planning steps in a new post to his blog.

This post is going to describe how I've ending up designing, what I consider to be a fairly RESTful web API. I'm far from being an expert, and this is definitely the closest thing to a RESTful API that I've ever created, so I'm not even experienced with REST APIs. [...] Until about 6 months ago, I'd always been sceptical of creating RESTful APIs, but I think I've had a few pennies drop since then that have made me fairly confident that I grasp the basics pretty well.

He touches on topics like: authentication, the Richardson Maturity model, HTTP verbs, sample request and response messages and some BDD-style tests to predict the output of a basic request.

On the Refulz.com blog there's a recent post introducing the __toString() magic method in PHP. This handy method allows you to define how to return an object when it's referenced as a string.

We started the study of PHP magic methods by learning about __get() magic method. [...] PHP is loosely typed language and same variable can be used or referred as string, number or object. The __toString() method is called when the code attempts to treat an object like a string. This function does not accept any arguments and should return a string.

Some quick code is included showing how it works - returning a combined string made from two private class properties when the object ($obj) is echoed out. They also show multiple ways of using the method in both pre- and post-PHP 5.2.

Lorna Mitchell is back with a second installment in her "Building a RESTful PHP Server" series with this new post about handling and routing the incoming requests. (You can find the first part about working with the request here)

This is the second part of a series, showing how you might write a RESTful API using PHP. This part covers the routing, autoloading, and controller code for the service, and follows on from the first installment which showed how to parse the incoming request to get all the information you need.

She shows how to grab the controller name from the incoming request (based on her previous code), create the object for it and execute the requested action name. Also included is a sample autoloader and a basic controller - a UsersController with "getAction" and "postAction" methods for responding to GET and POST requests.

In this new post to her blog Lorna Mitchell starts off a new series (based on popular demand) looking at building an RESTful server in PHP. Back to basics - no framework, just PHP.

In the first part of this (probably) 3-part series, we'll begin with the basics. It might seem boring, but the most important thing to get right with REST is parsing all the various elements of the HTTP request and responding accordingly. I've put in code samples from from a small-scale toy project I created to make me think about the steps involved.

Her "basics" include:

• the routing to send everything to the main index file (a "front controller" of sorts) with the .htaccess settings included
• Handling the incoming request with a "Request" class
• Parsing the incoming parameters from the "php://input" stream

Sharon Levy has a new post to her blog showing a trick she's come up with to show the PHP version information (usually found in the phpinfo) even when it's disabled.

Sometimes the most crucial, basic piece of information can seem so hard to find. For example, suppose you wanted to find out what version of PHP your remote webhost provides to shared hosting users? What would you do? [...] For development purposes it can be helpful having phpinfo() available, but on a live shared host, you may discover as I did recently that it is no longer available; your host may have disabled it.

She includes three other ways you can use to get the version of PHP you're working with:

• If you have command line access, running "php -v"
• Using the phpversion function (or PHP_VERSION constant)
• Appending a certain value to the URL (only works in some cases)