Recently I have been handling the security of some sensitive data. I had originally been encrypting/decrypting data with a symmetric-key system using mcrypt for PHP. This was due to the web frontend and the backend existing on the same server. However for security purposes I am now separating the frontend and backend onto different servers, so that there is no way the web accessible frontend, whether compromised or not, can get at the data it inserts into the database.

In order to do this, a asymmetric-key system is needed, such as public-key cryptography. Googling for examples of this in PHP, there doesn’t seem to be any results of this other than the php OpenSSL extension documentation, and systems that try to reinvent the wheel with their own implementations.

Using the PHP OpenSSL extension it is fairly easy to sort out a secure system for encrypting data with one key that only can be decrypted with another.

Update 1st June 2009 – Added a note mentioning about case-insensitive comparisons in MySQL.

I’ve been looking at generating random identifiers in PHP, and making sure they are random enough. Looking at the PHP function uniqid(), and its suggested better token, I don’t think this is an adiquate enough way:

$better_token = md5(uniqid(mt_rand(), true));

I was looking into getting Google Sitemaps running today, and didn’t find much in the way of WordPress-MU compatible sitemap plugins. The only article I found was on a website that wasn’t responding, and looking at its Google Cache, it was a bit dated.

All of the plugins I could find seem to put the sitmap.xml file in the WordPress install directory. The problem with that is that the directory isn’t apache writeable, which means you have to touch and change the permissions of the files manually. Also with WordPress-MU, there may be more than one blog in use for that installation, so you can’t serve these multiple blogs’ sitemaps from a single location.

I took a few of the cached article’s ideas and made them easier to do. This guide will work on WordPress-MU 2.7 (the latest release).

Update 1st May 2009: Good news, Zend Framework 1.8 defaults to no longer suppressing errors in loading classes (not sure how much of their library has been converted to use this though)

A good article on the autoloader changes:

http://devzone.zend.com/article/4525

Several times during website development, I have come across scripts which die without errors, so I try and debug the pages, finding which functions/includes it is getting to before it dies, narrowing it down. The code I usually come across which causes this is in the Zend Framework in the form of:

@Zend_Loader::loadClass('My_Class');

Zend_Form, the latest and greatest addition to the Zend Framework in version 1.5, is an infusion of the best bits of Zend_Filter_Input, and the Zend_View_Helper system. At first glance it looks like the ideal system for setting up from the simplest to the most complex forms, and this is how most people will see it.

I recently delved into the use of it, and was instantly shocked at a fatal flaw in its design. Where am I supposed to put it?

In my attempts to create the most Digg resilient website, I decided there was only one thing for it, full page-based caching on the server.

My first foray into this was trying to implement Zend’s Zend_Cache_Frontend_Page.