Transcending Frontiers

FCKEditor is a third party WYSIWYG editor for websites that is used in a great number of applications across the web. The problem with using third party applications is that you can never be sure of the quality of the code, or of the security model they’re enforcing. In the case of FCKEditor the default installation can be extremely insecure and information on how to secure it is pretty thin on the ground.

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.

These days I’m using a lot of asynchronous calls to get data and dynamically build the UI on the client side. It generally allows a far nicer experience to be provided to the user, being able to update parts of the UI without reloading the whole page is one of the first steps to your apps being able to wear a Web 2.0 moniker.

The general pattern for me these days has become :

var callback = function CallBack(data) {
    ... Do Some Processing ....
}

var input_data = GatherData();
MakeRequest(target_url, data, callback);

I tend to use jQuery and so my callback is passed in the returned data from the target_url. My call back function then generally performs some tasks on the UI based on what it receives.

The problem though is that in this pattern you can’t get any data from the context when MakeRequest() is called into the scope of CallBack. It’s a scoping issue that falls outside of this little post, but if you’d like an explanation of how Javascript handles scope of variables then you can Google for Javascript scope chain or take a shortcut to this article. Essentially when the call is made to CallBack() all it will have is it’s own variables and any globally accessible (window) variables.

This week though I had a thought and worked through it with one of my work mates, Tony. If you passed in a function that had the scope that included the context you wanted to pass, then maybe you’d be able to access whatever data from the callee you wanted. It turns out that this does work.

The way to do this is pretty simple, and I used it to create a simple function that would grab data and then populate a select element with options. In this case the context I’d like to keep is which select element is the target.

Say that I needed to run this over a bunch of select elements in quick succession then as the callbacks were issued they may end up out of the initial execution order, so the target element isn’t reliable if it’s been stored in a global variable. I could pass it in as a variable that would come back from the page that is returning the data but that just smells bad to me. I think potentially JSONP is an alternative too, but this felt like the right way.

$.getJSON(url, input_data,
	(function(target_element) {
		return function(response_data) {
			var html = [];

			for (var i = 0; i < response_data.length; i++) {
				item = response_data[i];

				html.push('' + item['value'] + '');
			}

			target_element.children(':gt(0)').remove();
			target_element.append(html.join(''));
		};
	})(target_element)
);

Essentially the main thing that has changed is that we are now running an anonymous function at the time that the AJAX call is issued. This anonymous function itself returns a function that matches the signature that jQuery is expecting for the callback function. The scope in which this function runs contains the target_element because it was passed into the anonymous function as a parameter. I’m tempted to say that it’s all crazy Javascript scoping, but in reality it’s very cool and very powerful.

If you want to see the execution order of this then just put a some logging into the anonymous function and the callback function and you’ll see what I mean. It will probably make it easier to see what is going on too.

I’ve run into issues trying to get around these problems before and thankfully as mine and the team’s knowledge of Javascript increases I’m finding better and better solutions. I thought my previous method of approaching this problem was quite hacky but now I don’t feel so dirty.

Thanks to Tony too for working through this with me!

If you’re a business owner maintaining a web site (really, who isn’t these days) do you find yourself waiting days for updates to your web site to be completed? Are you constantly frustrated at the time, money and effort to interact with your web team to get things done?

Nearly every web site owner asks these questions and more. If you weren’t sure that you needed a CMS (Content Management System) or you didn’t know what one was, let me enlighten you.

Here’s 5 reasons how a CMS (like our own AuroraCMS) can benefit your business.

Timely changes

A CMS gives you the power to bring your changes to the web as fast as you can type. Changing content on the fly, updating mistakes or misinformation and uploading documents can be performed with ease.

Lower maintenance costs

Sometimes it can cost several hundred, or even thousands of dollars for a few content changes to a web site. With a CMS you can change and update as often as you like, at your convenience, for no extra cost. A CMS takes the pain and stress out of maintaining your website.

Anyone can update the content

Now you don’t need someone with web knowledge to maintain the website. As long as you have basic computer skills (word processing level), you can easily take control of your web site. A business owner, team member or secretary can take care of everything.

Site design remains intact

Using software like FrontPage can render your website a disgrace after a round of changes. A CMS prevents you from altering the sites basic template structure and graphic design. This means that you can trust anyone to change your content with a minimum of fuss.

Tired of your existing site design? Have a new template designed up and drop it right in. Your content will already be there and working.

Access from anywhere, at any time

Forget FTP programs or clunky software that only works on one computer in the office. On any computer load up the web browser and log in. Even away on business or using the laptop on the train to work you can draft up or publish an update.

Convinced? Then get in touch with us to discuss AuroraCMS today.

Just moments ago, we sent out a newsletter (view here) to all our customers introducing them to our February web site give-away. If you or someone you know is thinking about building a web site, this may come in handy. The condition? If 5 or more web sites are commissioned this month, we will draw one lucky winner out of the coveted TFG stubby holder to have their site paid for by us.  

You can get in contact with our team here to get your site underway. At the end of the month if you’re the lucky customer, any monies paid to that date will be refunded.

The winner of this give-away will receive a standard business web site (valued at $4,500) free. We’ll also couple this with a 12 month subscription to our flagship product AuroraCMS. AuroraCMS will enable you to maintain and update your site for the next 12 months with no more to pay. 

Also this month we’ll be donating $250 from every web site commissioned to the NAB Victoria Bushfire Relief Fund to help those in need.

If you’re interested in signing up to our regular newsletter, please do so at our web site. You can also follow us on Twitter or on our Facebook page for more updates.

This morning I had to solve a problem that involved an application inside an IFrame not keeping it’s session state. I’d solved this problem many times before, a long time ago, in a galaxy far far away, but still it stumped me again!

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.