Charles Reace
PHP Musings

Note: See the comments section regarding the change in the EULA.

As I posted at PHPBuilder.com, Ghrome, Google's entry into the browser wars, now has a beta version available for public download (Windows XP/Vista only, for now).

My initial impression is that it works just fine and seems pretty "peppy". For me it has one bug so far: I cannot scroll up via the touchpad on my notebook PC, though it scrolls down just fine. (I've submitted a bug report on it, and it appears others have had the same problem.)

Read the rest...

Due to the recent number of "Spam" comments received on this blog, I have been forced to implement the restriction that all users must be registered and logged in before they can submit comments. Sorry for any inconvenience; once again you can thank the spamming scum of the world who do their best to ruin the interenet for the rest of us.

I recently downloaded and installed the Community Edition (i.e.: free) of the Aptana Studio IDE, which includes a PHP plug-in. My initial impression is a good one, and at some point I'll probably write a review here; but for now I just wanted to report on a problem I encountered and the very simple fix that resolved it.

The issue was that when I clicked on the File -> New... menu selection, it listed options for several types of files to create (HTML, JavaScript, CSS, etc.), but there was no option for a new PHP file. This causes two problems: you cannot then have it start with your desired template PHP text, plus the editor does not start in what I'll call a "PHP mode" where features like syntax highlighting and parse error checking work.

Read the rest...

I just saw this post by "jazz_snob" posted at PHPBuilder.com, suggesting a means to secure untrusted image files. The basic idea is to use PHP's GD image functions to create a copy of the file. As doing so would decompose the specified file into GD's native bitmap format, and then recompose it into the desired image file type, any embedded "nastiness" within the original file ought to be left behind. It could be implemented into a function something like:

<?php
/**
 * Copy an image to help ensure it is not "infected"
 * @author Charles Reace (www.charles-reace.com)
 * @param  string    path to image file to be copied
 * @return resource  GD image resource, boolean false if error
 */
function secureImage($filePath)
{
   $sizeData = getimagesize($filePath);
   if($sizeData === false)
   {
      user_error(__FUNCTION__ . "(): Unable to get imsge data");
      return false;
   }
   list($unused, $type) = explode('/', $sizeData['mime']);
   switch($type)
   {
      case 'gif':
         $fh = imagecreatefromgif($filePath);
         break;
      case 'png':
         $fh = imagecreatefrompng($filePath);
         break;
      case 'jpeg':
         $fh = imagecreatefromjpeg($filePath);
         break;
      default:
         user_error(__FUNCTION__ . "(): Unsupported image type '$type'");
         return false;
   }
   return $fh;
}

// Sample usage:
$fh = secureImage('bg.gif');
if(!$fh)
{
   header('HTTP/1.0: 404 Not Found');
   exit;
}
header('Content-Type: image/gif');
imagegif($fh);

If any of you readers happens to have access to an "infected" image file and a safe sandbox where you could test the above, I'd be very interested to know if it does, in fact, filter out the non-image virus or whatever is embedded, or at the very least reject it with an error.

Here's a little trick I discovered the other day for passing application settings around in an object-oriented implementation. You can create an interface that defines any number of class constants, then any class you define that needs those constants needs only to implement that interface. For example:

<?php
/**
 * Define constants for use in other classes
 */
interface Constants
{
   const DB_HOST = 'localhost';
   const DB_USER = 'username';
   const DB_PASS = 'abc123xyzr';
   const DB_NAME = 'test';
}

/**
 * Database class based on MySQLi class
 */
class DB extends mysqli implements Constants
{   
   public function __construct()
   {
      parent::__construct(
         self::DB_HOST,
         self::DB_USER,
         self::DB_PASS,
         self::DB_NAME
      );
   }
}

The advantage of this over running some configuration script that sets the constants is that by implementing an interface, it becomes immediately visible that the class requires that interface. If on the other hand you depend on independently setting constants in an include file or such, then if you try to reuse a class that uses those constants, it will not be immediately obvious that they are needed until you start testing it in the new implementation.

The main limitation is that interfaces cannot have class variables, only constants. If you need application-wide variables for your object-oriented application, you'll either need to instantiate a class that has those variables and pass it to each object that needs it, use a singleton pattern class (which can have the same disadvantage of globals in that the fact that it is required can be hidden inside a class), or look into something like using a registry pattern class.

Here's a little something I came up with today for dealing with strings being moved from PHP into JavaScript code. The problem is that if you have some sort of textual content in your PHP script (perhaps the result of a "screen-scraping" operation), if you try to directly use it within some JavaScript being output to your page, you'll run into all sorts of headaches due to newlines, quotes, etc. For instance, the following will not work:

<?php
$html = file_get_contents('http://www.charles-reace.com');
echo <<<END
<script type='text/javascript'>
var htmlText="$html";
document.write(htmlText);
</script>
END;
?> 

But, we can urlencode the text on the PHP side, converting all those problematic characters into the encoded form. Then we can decode it in JavaScript via its unescape() function. On the PHP side we need to use rawurlencode rather than just urlencode(), as the latter replaces spaces with "+" characters, but the JavaScript unescape() does not convert them. Now we can change our test script to:

<?php
$html = file_get_contents('http://www.charles-reace.com');
$encoded = rawurlencode($html);
echo <<<END
<script type='text/javascript'>
var htmlText="$encoded";
document.write(unescape(htmlText));
</script>
END;
?> 

Now the page generates no JavaScript errors and outputs the text as expected.

Just a few days ago I recommended using filter_var() with the FILTER_VALIDATE_EMAIL argument as a convenient means of validating email address formats. However, Phill Pafford (ReliableSource.org) pointed out at WebDeveloper.com that there was a security bulletin suggesting a potential danger due to this validation allowing linefeeds in certain situations. I did a little testing, and sure enough, I found that if the email ends in a linefeed character, it still passes validation.

<?php
header('Content-Type: text/plain');
$email = 'foo@bar.com';
$len = strlen($email);
for($i = 0; $i <= $len; $i++)
{
   $test = substr_replace($email, "\n", $i, 0);
   $result = filter_var($test, FILTER_VALIDATE_EMAIL);
   var_dump($result);
}?>

Which outputs:

Read the rest...