People seem obsessed with captcha these days.

Small web sites that I know couldn’t possibly get more than a few enquiry form submissions a week come looking for it.

I, with 13 years experience of the Internet and decent eyesight have to repeatedly re-attempt registration on websites where I want to do scary things like buy products.

Try signing up for a windows live account. Only a blind person can do it at the first attempt. Not because they can hear the audio (their hearing is many factors better than the sighted, but not that good), no, they can deal with captcha easily because any Internet literate person with sight difficulties are aware of all the tools and plugins that can defeat captcha easily.

In no particular order, these are the reasons I really, really do not want to put captcha on your website:

• You don’t need it. Have you had more than 1 spam submission in the last 2 weeks? Oh I see, all the OTHER sites have it. Like what, Google? Microsoft? Ebay? I admire your self confidence, but I’m not sure your site or service is quite there yet.
• How dare you put the onus on the person you want most to interact with you: a potential customer, collaborator or Internet stalker, and make them jump through an extra hoop simply to register or contact you. Do shops take fingerprints at their doors lest a shoplifter gain entry?
• It is lazy to use captcha. If you really have a problem with spammy signups, contact form submissions etc, a bit of imagination on the part of you and your developer can solve this problem without sticking it to the visitor. Email verification. Spam Filtering. Bad Behaviour. Akismet. It is your problem, so put a bit of effort in.

I have lately been doing quite a bit of work using the SilverStripe CMS, which also has a built in development framework, Sapphire. This is the open source child of SilverStripe, a local company here in Wellington.

Version 2.3.0 of SilverStripe comes with a stable version of ModelAdmin, a really handy new tool I have been playing with in the CVS version prior to release. You can see a video of Ingo Schommer from SilverStripe giving an overview of ModelAdmin here. He also has the bones of the presentation up on Slideshare which isn’t as long but you don’t get to have Ingo’s germanic voice caress your ears.

Issues:

HTMLText fields

Modeladmin does not seem to like HTMLText dataobject fields at the moment and their corresponding form field types, HtmlEditorField. In my local WAMP this causes an page to pretened to load for eternity (though I gave up after about 90 secs so cannot fully confirm the eternity thing…).

I don’t see this as a major issue: html fields are best suited to the Site Content tab where all that stuff currently takes place anyway. There seems to be a bug report in for this issue anyway.

Scaffolding

ModelAdmin makes it super easy to give your data a CRUD (Create, Read, Update Delete – thanks Ingo!) interface.  If you have a dataobject with defined relationships (has_one, has_many or many_many), ModelAdmin will create these as drop down lists in your create/edit forms right off the bat.

This is super but right away I noticed a problem: these drop down lists for component dataobjects have no sorting on them. Thus my list of 2,500 New Zealand towns was not in alphabetical order. Far from ideal.

You can work around this by defining your own form via a getCMSFields function for the dataobject.  This allows you to populate your drop down fields via DataObject::get, allowing you a much greater level of control. 

Tip 1: make sure you define it as a new fieldset: $fields = new FieldSet();
Tip 2: use fields->push: $fields->push(new DropdownField(‘MyDataID’,'My Data’,$MyArray->toDropDownMap(‘ID’, ‘Name’)));
Tip 3: See I used  MyDataID as the field name where the field is called MyData. This had me confused for a bit as ModelAdmin was not capturing the input when I was calling the field MyData.

Assuming you avoid the pitfalls I made above, you can create a dataobject, set it up in ModelAdmin, and in 5mins have a back end administration area for your new data object. Fantastic!

Quite often when I encounter these types of “one size fits all” dataobject management tools, they always lack just enough to put you off using them, but I think ModelAdmin passes with flying colours. It is already being tried out in two websites under development.

Since I no longer manage servers directly, I have removed the GSM phone attached to my office server, sending me text alerts whenever a server or service is down.

I do wish to keep an eye on client websites of course though, as well as this one (which has had some small downtime issues in the past month due to some capacity issues with it’s host).

There are a plethora of website monitoring services out there, but the one I decided to take for a test drive was Site24×7.com. It offers the usual monitoring of a website and sends email and text alerts when a site is down. Best of all, it is free!

I had my concerns about the quality of the service given it is free – it is the kind of thing I would happily pay 10-15 euro a month for. I have checked the logs a few times and there are plenty of visits from the monitoring bot and it has reported downtimes on the sites it is monitoring within a minute or two. All in all, it seems a quality service.

One element which I am just about to take a look at in more detail is it’s ability to monitor transactions. This would allow you to not only ensure a site is up, but that it is functioning correctly by say, performing a search or adding something to the website’s shopping cart.

In doing so, you can ensure that the database server is running ok too, or nobody has made a change to your code that has broken the site!

Here is an idea for all those big supermarket chains out there: as customers enter the store, give them an RFID tag to wear. That way, with the use of some strategically placed readers, customers could be tracked right across the store. Store managers could identify where people spend most of their time, what aisles are popular, what spots on a particular aisle people slow down at (there might be a promotional item at that spot). The possibilities for gathering useful data are endless.

So why don’t they do it? I’m pretty sure most people would give them a two-fingered salute and take their business elsewhere. Unless all the supermarkets did it at the same time and then we would have no choice.

When it comes to the web, it isn’t a person’s body movements a website owner wants to know about, it’s their mouse movements. After all, unless you are visually impaired, the mouse is the manner in which most users interact with a website, hovering over links, scrolling, clicking etc.

A new web service, ClickTale, has come up with a way of recording these actions so that website owners can record and later review, every mouse movement and scrolling action a user has made throughout a given website on which it’s service has been installed. I haven’t used the service but from what I’ve read and seen of the client side javascript it loads on a user’s page, it makes use of some AJAX wizardry.

Clearly, this is certainly a very useful tool from the website owner’s perspective, but I would members of the general public be so happy about it if they knew it was there?

It has some great applications in beta testing, usability testing and debugging of websites, but I wonder if it isn’t going just a bit too far for general use? Just because you can do something, doesn’t mean you should.

ClickTale do address privacy in their FAQ, I’m parphrasing here, but it boils down to “we aren’t gathering any personal information on you, so it’s ok”.

Lets translate that back into the real world: “If I follow you around town all day recording your every movement, but I don’t ask you your name, thats acceptable”.

I’m not so sure.

Like I said, ClickTale looks like a great service, and I wish the guys every success, but it points to an issue that is becoming more and more relevant in relation to the use of the web’s belle de jour, AJAX.

AJAX can be used to capture lots of information, from mouse movements to form inputs, without the end user knowing about it, or before they have pressed a submit button. Gone are the days when a user knew they had to hit the submit button before their info was processed by a website.

If we are going to be using more and more AJAX in our web applications, and I don’t see why we shouldn’t (I just spent the past 2 days working on something that uses AJAX), we had better make sure we don’t freak users out and have them switch off Javascript in their browsers.

None of the websites I have custom coded from scratch have ever been hacked. I’m not saying I’m the world’s best web developer, I will assume my readership is smart enough to draw that inference for themselves!

On the other hand, several sites that I have worked on that used “off the shelf” type programs for CMS or e-commerce have run into problems of late. It stands to reason that if enough people use and abuse a product they will eventually find flaws and security holes in it. In every case, the security exploits had been known about for quite a while and patches/upgrades available .

So why weren’t things patched? Well, the reasons for not patching up mainly fell into two areas:

1. There was no longer a technical resource available to perform the required actions
2. The site had custom modifications that prevented a straightforward patch/upgrade

Now as a professional web developer I can’t really do much about it if a client doesn’t want to pay me or someone else to keep the site updated and patched. I’m unlikely to be overly pro-active about getting in touch with customers from a few years ago that might need to upgrade when a particular security flaw is uncovered, but I would drop them a mail if I thought it affected them.

I can understand a customer’s reluctance to engage me on an ongoing basis or even to bring me back in every year or so to perform updates. Most of the projects I do are brought to a stage where the site or web application can be managed and operated by non-technical users, the idea being that the customer stumps up a higher up front cost for a system that doesn’t require regular interventions and updates from a techie, thus saving them money in the long run. I think though, for my part I will have to flag the necessity of security updates to clients outside of any other ongoing maintenance/support contracts which they may or may not want.

Most of the off the shelf systems such as Joomla!, Mambo or X-Cart (which I use for some e-commerce projects ) have very easy patch/upgrade systems that would even allow a non-techie with a bit of bravado (and hopefully a database backup!) to perform the update.

This assumes however, that the core code and functions of the website application remain intact, and this is not always the case. The customer might require an extra piece of functionality that is not currently present and must be custom coded. In this case, the preference would be to develop some sort of module or plug in that stands outside of the core code, allowing a clean upgrade path. There is no guarantee your own custom code will still work once the update has been run, but in most cases it should be straightforward enough to do, and at least the main body of code has been updated without much trouble.

In instances where there have been modifications to the core code, the task becomes more complex. The developer then needs to see what the upgrade/patch is changing, and then manually apply the code updates/patches using some sort of text file comparison/merging tool. In short a bit of a nightmare!

There are often very good reasons at the time of development for modification of core code in this manner. It isn’t always possible to code add on functions as separate code or indeed source a program that does everything you want, exactly as you want it to, and if the customer has a genuine requirement for a particular feature, then who am I to argue?

I might not argue, but I should underline the seriousness of breaking the upgrade path to a product. It really adds significant costs to future upgrades which in turn might have the consequence of necessary updates and upgrades being put on the long finger.

It isn’t always the customer though. Sometimes the web developer can be lazy and simply lash something in any old way without worrying too much about how it might affect things in a years time when an upgrade is needed. After all, he or she will have retired to a non-extradition Caribbean island by then. As a developer it is important for me to ensure a clean path to future updates/upgrades for web applications wherever possible.
If your site is running an off the shelf web application, it is important that you make yourself aware of any security updates and alerts that come from the developers of the application. Even if it is just to check that your techie is applying the necessary updates, it is an important step. Ultimately it won’t be the guy who did the site 3 years ago that suffers most if your site is hacked using a year old exploit…