Andy Thompson

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 run bind9, a DNS server, on my Ubuntu laptop so that I can use more advanced local dns resolution than what /etc/hosts can provide, such as wildcard domain names.

The problem is that in order for me to be able to use that DNS server whilst being able to resolve internet domains at the same time used to require me to do two things:

• Edit /etc/resolv.conf, and change nameserver to 127.0.0.1
• Edit /etc/bind/named.conf.options, and add a forwarder to the nameserver IP that was previously in /etc/resolv.conf

When I upgraded from Ubuntu 8.04 (Hardy) to Ubuntu 8.10 (Intrepid), a dhclient-exit-hook script I wrote no longer functioned.

dhclient-script was previously used by dhclient so that whenever the dhcp changed, it would reconfigure the interfaces, generate the /etc/resolv.conf, and run scripts who’s intention is to modify the /etc/resolv.conf file based on the dhcp settings. These scripts are located in the folders /etc/dhcp3/dhclient-enter-hooks.d/ and /etc/dhcp3/dhclient-exit-hooks.d/.

Reading up on the problem, thanks to perlhead on the Ubuntu Forums, it appears that since NetworkManager did the same function as dhclient-script, which got in the way of NetworkManager’s plugins, so dhclient-script was disabled.

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.

In a further attempt to modify my websites so that they can withstand the Digg Effect, I have looked into getting Nginx, a lightweight http server, to perform page-level caching.

Nginx can act as a reverse proxy, sending any HTTP request sent to it to another web server. It can also store the response to file, which can later be served on future requests.

Update 2010-04-10 – Nginx >= 0.7 now has proxy_cache* directives, to do this in those versions, see Page-level caching with Nginx