Securing CMS

Only a short one today.  At work we had an issue that we needed to secure our CMS to only be available for internal access. I had a few ideas, but after some research I found something very cool that was apart of IIS (6 and 7).  There is an option to secure a site or directory (or application) to only certain IP's. Its called "IPv4 Address and Domain Restrictions".

The reason why I'm blogging about this is because this is an easy way of adding an extra layer of security to a normal CMS.  Most CMS's are available for running locally, and this means that they are something that can be easily access, and the code can be analysed.  From a security point of view, this is a concern.  To mitigate against this, securing the main administration directories (login etc) using the IP restrictions in IIS adds an extra layer to the security of the application.

The easiest way to use this is to deny all access, and then only allow the IP's that you want to access the directory (usually internal and one or two external IP's).

Hope this helps.

Changes to Facebook API

Today we had something interesting happen at work.  We had just implemented some Facebook functionality on a project that was ready for release, and just before it was signed off today, a final end to end test was completed.  Part of that test was to test some functionality with social networks.  When the Facebook functionality was tested, it failed.

The functionality was meant to pre-populate the message box with a message that the user updated.  On Wednesday this was working, and today it wasn't.  Lets just say that this caused a few questions to be asked and a few worried people moving the corridors.  How can functionality that was working one day break the next when we made no changes to the code?  After some searching the web (Google is mostly always your friend), I found my answer.  Let me break it down for you.

Firstly, we were using the Javascript Library, specifically the FB.ui functionality. Using the Feed dialog box, we would place our user augmented message into the message box, which the user could then update and publish on their wall.  Now looking at the reference from the Facebook developers page (seen here http://developers.facebook.com/docs/reference/dialogs/feed/ ) the message property is what we used to pre-fill the dialog box. As you can see there is a note on the property that states that the field will be ignored on the 12th July, 2011.  So why was it still working two days ago (3/8 to be specific)?

Before I go into that let me first look at the policy for Apps in Facebook. If you go to the policy page (seen here http://developers.facebook.com/policy/ ) and read section 4 sub section 2 it states that an app will not pre-fill any fields.  (Then in the following sub section it states that the user can give permission for an app to post on their behalf. That is a task for next week.)

So back to the question, why did it just stop working?  If I were to guess, and that is all that I would be doing, I would say that Facebook just got fed up with people not looking at the policies and following them.  Apps should only pre fill the form when the user has done it some where else in the work flow.  I would say that there were plenty of apps that just didn't follow the rules and they just decided to enforce the rules.  And to be honest, I have no problem with them enforcing their policy.

Now, what is the lesson learned from all this?  Is it that we should not trust Facebook?  I would say not.  For me? The lesson is that when you are using third party services you need to be aware that what you don't control what happens with them.  You should intermittently test the services, just to make sure that they work as expected.  That is if you want to make sure that your sites and applications maintain the functionality that you build them with.
Hope this helps!