There are a few things that can be done to improve the security of FCKEditor after installation so hopefully these few pointers will help.

Integrate Your Own Authentication
You can integrate some basic authentication fairly easily using an htaccess file and the php auto_prepend directive. This directive will basically tell the php engine to prepend any script with the file that you specify, it’s essentially the same as issuing a require() call before each page is run. We use this to run our own authentication scripts before access to any part of our application is run. There are parts of FCKEditor that are freely open to the public, so this is quite important unless you want your site to have anonymous users uploading anything to you.

Turn Off The PHP Engine in Your Upload Directories
FCKEditor does have some very basic checking included to try and stop users from being able to upload any sort of executable code to your application; but none of it works very well. The best way to circumvent this is to stop PHP from functioning inside your upload directories. What this means is that although a user could circumvent your security and upload some malicious code to your server all that will happen is your web server will serve back the content as plain text.

Remove FCKEditor’s Testing Pages
FCKEditor includes some basic forms that allow you to check that your configuration is correct for uploading and browsing your website. These forms if they remain publicly available provide a very handy access point for users to upload content to your site that they shouldn’t be. The file exists in /editor/filemanager/connectors/test.html and is there only to allow you to test the connectors, you should be deleting it. This step will not stop those progressing up to step one or two, but I see this as putting up some fake security cameras, it’ll stop some lazy criminals.

Hopefully these tips will help anyone that is using FCKEditor and is worrying about any holes in their security this might open up. Obviously these can be generically applied to any application that allows uploading to occur, however with FCKEditor being quite prominent in older applications it’s probably worthwhile just having a look at your app to see how secure your editor really is.

In this example we had two client websites we’ll call site-a.com and site-b.com. Site-a.com had a page that contained an IFrame which sourced it’s content from site-b.com. The page on site-b.com allowed the user to log in to the application that resides on the site-b.com domain and then click on various links that would take them to other areas in the site-b.com application.

This worked perfectly in Firefox and Safari, but in IE7 it failed and would not let the user log in. After setting up a test environment on my virtual machine and repeating the bug I went looking for a solution.

It turned out that what was required was a declaration by site-b.com that it was okay to do what I was trying to do. It seems that as long as site-b.com declares that it’s safe then the browser assumes this to be the case and it all starts to work.

The way this is done is through adding P3P info to the header of the response. Essentially what this does is say to the browser that your application is okay with taking information from other domains. Rather than relying on external security measures, you’ve taken the steps yourself to develop a secure application. This sort of setting can also be used for single sign on situations too where your cookies need to be accessible across domains and applications.

Typically it’s as simple as adding :

header('P3P: CP="CAO PSA OUR"');

to the page. You could also add it on the server level if required, but in this case it all takes place in an extranet module so it’s perfectly suitable to be applied only on one page. There are quite a few options that you can find on the P3P Specification.

So that’s how you get cross domain cookies to work with PHP. It’s much the same in other web frameworks, you just need to work out how to modify the headers in the one you’re using.

public function testNameIsUnique() {
	$test1 = $this->BuildValidDiscountType();
	$test2 = $test1;

	$test1->Save();
	$this->assertTrue($test1->id > 0);

	$this->setExpectedException('DiscountTypeException');
	$test2->Save();
}

This code shouldn’t have worked as far as I was concerned, in fact I was expecting an exception to be raised. Instead it was working and after a little debug tour I found that my $test1 = $test2 line was causing $test2 to be a reference to $test1, not what I wanted. This caused my update method to be triggered instead and of course the name is still unique.

It only required a small change to that line, using the clone specifier :

$test1 = clone $test2;

After that everything went as expected and I knocked off another test, and added to my PHP knowledge.

I hear you ask “how is that a negative side effect?” It meant that I put off the investigation into bench marking and tuning our server platforms simply because the move to newer hardware gave us significant gains. I had planned on doing some configuration tuning and system refinement, but the sheer increase in processing power meant that I didn’t bother with it back then.

Today, however, I decided to investigate what the addition of a PHP opcode cache would provide, and I was very happy with the results.

I came across an issue with running APC, the opcode cache developed by Rasmus and other core PHP developers, alongside the Zend Optimizer. The two are incompatible so you’ll have to play favourites and pick one or the other.

Installation of APC is easy on Ubuntu. There’s many guides online, but I found this one to be the most succinct. You end up installing the following packages (note: I didn’t have build-essential initially and PECL couldn’t build the package because I was missing make):

mlambie@prime:~$  sudo aptitude install php-pear php5-dev apache2-prefork-dev build-essential

The installation of APC is easy via PECL:

mlambie@prime:~$  sudo pecl install apc

Then enable the module by creating an apc.ini file:

mlambie@prime:~$ cat /etc/php5/apache2/conf.d/apc.ini
extension = apc.so
apc.enabled = 1
apc.shm_size = 48
apc.include_once_override = 1
apc.mmap_file_mask = /tmp/apc.XXXXXX

I ran some benchmarks using Apache Bench. The results were very encouraging. I saw a reduction in the time per request fall from 91ms to 37ms (250% improvement). The volume of requests per second increased from 11/sec to 27/sec (245% improvement). Lastly, 98% of all requests are served within 639ms instead of 1165ms (182% improvement).

Each actual apache process saw a significant memory reduction too, from 26MB down to 20MB (almost a 25% footprint saving). When you’ve got multiple processes running the reclaimed memory adds up quite quickly.

I found the figures staggering, and the improvements are actual, real things that are visible when interacting with the sites and applications hosted on prime.

It’s fair to say that we more then doubled our performance, from a single server, simply by adding PHP opcode cache. If you’re not running one on your server, you might want to consider why.

Today I faced an issue due to the size of my objects. The problem essentially came down to the fact that for the largest objects such as Contact objects the amount of data passed back to the client when doing AJAX calls was pretty sizeable. I wanted to write a function that given a set of property names all the returning objects would be stripped of all but those properties.

I didn’t want to write a function for each set of properties I’d return, so I wrote a generic function that given an array of property names that was all that would be returned from that object and it was surprisingly easy and I think in the end highly dynamic and useful.

It uses the PHP array_walk() function which I’ve never used before. It’s a lot like the Array.each() methods that many other languages have.

	private function GetContacts() {
		$filter = RequestQuerystring('filter');
		$properties = RequestAll('properties');

		if (isset($properties)) {
			$properties = explode(',', $properties);
		}

		if (isset($filter)) {
			$contacts = [large_objects]
		}

		if (isset($contacts) && is_array($properties)) {
			array_walk($contacts, 'mod_ajax::FilterObjects', $properties);
		}

		echo json_encode($contacts);

	}

	private static function FilterObjects(&$object, $key, $properties) {
		foreach (get_object_vars($object) as $k => $v) {
			if (!in_array($k, $properties)) {
				unset($object->$k);
			}
		}
	}

Basically for this array of large objects on each one we call FilterObjects. That has to be a function or static method which I learned as I went. The object is passed in by reference so that any change made to it is reflected in the original array, and it just goes through the variables (properties) of the object and kills anything that isn’t in the allowable parameter list.

This allows me to trim large objects dynamically for any of my client side calls for data and I think is definitely going to save me time in the future. I remember when I first started using PHP I wrote a function for each object to spit out XML, then I progressed to JSON, now I’ve got a nice filter method.

I still feel like there must be a better way to do things, but quite possibly that would exist in another language.

This took me a few minutes today to work out and find an answer on Google so I thought I’d share it.

I had a string that I was posting from a form and while Firebug on the client said that the string was valid, on the server side PHP’s json_decode() function was returning me a NULL indicating invalid JSON. I spit out the string using good old var_dump() and I could see straight away that I would need to strip some slashes from it, but I couldn’t figure out why.

I don’t like to simply know how to fix something, I like to know why it was broken in the first place! A bit of Googling gave me the answer, it turned out to be because of the magic_quotes setting in PHP.

Instead of just wrapping everything in a stripslashes() call I decided to write a wrapper function that will take into account whether magic_quotes is on or off. It will also allow me to do whatever I want later one if I wanted to parse a particular type of data or something.

Here is the code. As you can see it’s nothing fancy, but it works and hopefully it saves people some time.

function _json_decode($string) {
	if (get_magic_quotes_gpc()) {
		$string = stripslashes($string);
	}

	return json_decode($string);
}