DevShed has posted the last article in their series on filtering input (from whatever source) in your PHP application. This time the focus is on cleaning up the GET and POST superglobals.

The [filter] library is also capable of cleaning up strings in arrays, as well in data coming from GET and POST requests and cookies. Therefore, this final article of the series will demonstrate how to do this with a few understandable examples, in this manner concluding this quick introduction to working with the PHP 5 filter library.

They show how to use each of the constants referring to these superglobals (INPUT_GET, INPUT_POST, INPUT_REQUEST, etc) to run through each of the values and check them against another filter.

Revisiting an earlier post dealing with superglobals and classes, Brandon Savage looks at an example of why its still a bad idea.

I asserted at the time that superglobals inside of a class violated some basic rules on what a class was supposed to do. Today, I am revisiting that discussion. The placement of superglobals inside a class creates an impossible situation for code reuse. [...] Ehat happens when we want to move this [code] to another site? Unless we leave our form fields named [the same] we'll have to modify the original code.

His alternative - a much better refactoring - lets the verifyCredentials method take in the username and password and has the calling script define where those come from, either from a local or global location.

PHPBuilder.com has the next articles in their "ABCs of PHP" series posted today, a look at variables - what they are and how they're used.

To many beginners the subject of variables is usually pretty scary, and often a reasonably difficult concept to grasp, the reason for this however is usually because most modern languages require some kind of indication as to what type of data a variable will hold, this in turn often confuses beginners because they don't know what type of data relates to what kind of type.

They describe variables (using sample assignments like strings and numbers) and talk some about scope and how it affects their visibility. There's also a brief mention of the superglobals there close to the end.

Some of you might have heard about the hacking of the phpBB.com website earlier this week. Well, Stefan Esser has posted a bit more about the vulnerability in the PHPList software that lead to the problem.

A few days ago phpbb.com was hacked through a super-globals-overwrite vulnerability in PHPList that was used by an attacker for a local file inclusion exploit. Details about the whole attack, written down by someone who claims to be the attacker, can be read here.

Stefan talks about the superglobal problem PHPList had - allowing the superglobal information to overwrite the variables inside the script without so much as a check. Example code shows how it was possible for the attacker to provide their own configuration file value to be opened via a stream wrapper.

On the SitePoint PHP Blog today Troels Knak-Nielsen takes a deeper look at two of the superglobals a lot of PHP developers take for granted - $_GET and $_POST.

When a PHP script is invoked by a web server, it is as the result of a HTTP request. A HTTP request has a target URI and that URI consists of different parts. One of these parts is the query. As the PHP process starts up, the query gets parsed into an associative array. And for some reason, somebody decided on the unfortunate $_GET, because it's what you use for GET requests - right? Wrong!

He points out that all HTTP requests, regardless if they're GET or POST will have that GET information (not necessarily in $_GET, though). He also mentions another commonly used (and sometimes abused) superglobal - $_FILES. His biggest gripe, though, is that the naming of the variables confuses the developer as to the true content of the HTTP request.

And I won't even comment on the nastiness of $_REQUEST.

The PHPBuilder.com site has a quick new tutorial showing how to upload images to your server via a PHP script (including some error checking).

One of the most frequently asked questions about PHP is "how can I use PHP to upload an image". In this article we'll discuss the details of how you can do just that!

Their script is done in three steps - an HTML form to accept the input, the PHP script to handle the upload (working with the $_FILES superglobal) and another HTML page to let the user know their upload was a success. When the file is uploaded, they check for a few things: the internal error PHP could throw, ensuring that the uploaded file exists and checking to ensure that the file is an image. Only then is it moved over to the true uploads directory to be stored.

In a new post to his blog, Brandon Savage makes a suggestion that could help in maintenance and debugging down the road - keep those superglobals out of your classes.

Let's ignore the security implications of the above code for just a moment, and focus on just the use of the superglobal. By using the $_POST superglobal array, we're effectively doing two things [in the example code]: relying on the field names and limiting code reuse.

He shows how to refactor the example into something a bit more reusable by changing the method call to pass in the given username and password instead of looking to the global for it. He does note, however, that there are some more correct uses for those superglobals:

There are some legitimate uses of superglobals in classes. One example is the use of the $_SESSION superglobal, which is often used for things like a user object. But I urge you to do so sparingly, when appropriate, rather than relying heavily on superglobals which are subject to change and may not give you the data you expect.

David Otton has a new neat PHP trick posted today - assigning references to global values.

What follows isn't so much a PHP trick as a fix for something that really should work, but doesn't. Although the manual implies that the behaviour described below is specific to Zend Engine 1, all my tests were performed against Zend Engine 2.2, PHP 5.2.5.

His example compares making a new stdClass both with and without a reference on the it and var_dumps out the result. The method with the reference fails silently, however and isn't able to correctly assign it to the global. He recommends a work-around though - setting it directly to the $GLOBALS superglobal.

Sebastian Bergmann has a new post today about a feature of the PHPUnit unit testing tool that has the possibility of breaking when objects are introduced - backing up the globals.

It is hard to test code that uses singletons. The same is true for code that uses global variables. Typically, the code you want to test is coupled strongly with a global variable and you cannot control its creation. An additional problem is the fact that one test's change to a global variable might break another test.

You can disable the backup option if you'd like by setting the $backupGlobals option in your test to false. This lets PHPUnit know that you want to leave the globals (and superglobals) alone during the run.

On DevShed today there's a new tutorial showing how to build file upload functionality into your scripts.

If you're a PHP developer who has built a certain number of web applications, then it's quite probable that you've already worked with HTTP file uploads. [...] First I'm going to teach you how to handle file uploads using a procedural approach, and then, with the topic well underway, by way of the object-oriented paradigm.

The introduce the beginners out there to the $_FILES array (a superglobal) that contains the details about the file(s) that have been submitted. Next comes the construction of a simple form and how to handle the submission on the PHP side.