Keeping Superglobals Out Of Classes
December 15th, 2008 @ 1:41 pmHave you ever written code like this?
<?php
class VerifyLogin extends UserObject
{
function verifyCredentials()
{
$username = mysql_real_escape_string($_POST['username']);
$password = mysql_real_escape_string($_POST['password']);
$passwordhash = MD5($username . $password); // Salt our PW Hash
$sql = 'SELECT id FROM userTable WHERE username = ' . $username . ' AND password = ' . $passwordhash . ' LIMIT 1';
$resource = mysql_query($sql);
if(mysql_numrows($resource) > 0)
{
$array = mysql_fetch_row($resource);
$this->userID = $array[0];
$this->loggedIn = true;
return true;
}
else
return false;
}
}
?>The problem here ought to be clear: we’re using a class exactly like we would in some procedural code. This is a problem.
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:
- We rely on our form fields always being called ‘username’ and ‘password,’ and our class breaks if they’re not.
- This object cannot ever be used for processing any other types of data, limiting code reuse.
This isn’t what objects are for. Objects are designed to take data and hold it, then act on that data. For example, our user object should information about that user. You might have methods that can act on that user, like promoting them to administrator or verifying their login credentials. In the latter case, you would need to take $_POST data but it would be much better to pass it in directly than to rely on the superglobal inside the object itself.
A better code snippet from a user object would look something like this:
<?php
class VerifyLogin extends UserObject
{
function verifyCredentials($username,$password)
{
$username = mysql_real_escape_string($username);
$password = mysql_real_escape_string($password);
$passwordhash = MD5($username . $password); // Salt our PW Hash
$sql = 'SELECT id FROM userTable WHERE username = ' . $username . ' AND password = ' . $passwordhash . ' LIMIT 1';
$resource = mysql_query($sql);
if(mysql_numrows($resource) > 0)
{
$array = mysql_fetch_row($resource);
$this->userID = $array[0];
$this->loggedIn = true;
return true;
}
else
return false;
}
}
?>In this example, we get to select where the $username and $password variables come from. Likely they’ll come from a posted form, but we have the ability to determine that for ourselves. This class is much better, because it is a true blueprint of an object.
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.
The original work of Brandon Savage.
No related posts.
Categories: Best Practices, Usability, Web ArchitectureTags: , classes, objects php 5, superglobals
Web developer, amateur photographer, traveller, and amatuer chef. Expect to find me writing code, visiting new places or trying a new recipe. I live with my wife in Olney, Maryland. Follow Me On Twitter!- Excited About PHP Again
- Rethinking The Technical Resume
- We The State, Not We The People
- Working To Defeat the Stop Online Piracy Act
- Diversifying This Blog
- What do you want the web to be?
- Why I Love Being An Engineer
- Validation Blind Spots Hurt Real Users
- Finding A Job Without A Recruiter
- Why Recruiters Are Bad For Your Career



[...] December, I wrote about the use of PHP superglobals inside of classes (link here). I asserted at the time that superglobals inside of a class violated some basic rules on what a [...]