Category Archives: Human Factors

On all human factors related to software development.

Password failure in WordPress Plugin

One of the great features of WordPress is the wide variety of plugins available. They often enable a lot of interesting functionality and integrations to other services not native to WordPress itself. Most of these plugins are developed by individuals or small teams independent of the core community – and often not with a keen interest in security, but an exclusive focus on “making stuff work”.

I’ve been using the WordPress “Google AdSense Dashboard” for awhile, and after the recent host of password leaks, I’ve been changing and upgrading password all around. This change lead to expose what I would call a critical password exposure in the plugin and so far caused me to remove the plugin everywhere I’ve installed it.

The issue was the following:

If the password to Google AdSense fails in the plugin, your username and password is displayed in clear-text on screen – in the dashboard when logged into WordPress. Where’s the catastrophic take away – the username and password seems to be stored in clear text (or at least stored by the plugin in a format which can be converted back to clear text), and secondly, apart from storing it somewhat carelessly the plugin even display the information on the login screen – apparently for each and every user.

HTTPS, SSL, TLS – What it does

While surfing the net, you often come across web agencies how promote SSL-certificates (or TLS security) on their products – or their ability to create “secure web applications” with SSL. Most users know HTTPS/SSL/TLS as the little lock, that promises “security” when visiting a page – but what kind of security it actually provides is rarely explained – and far worse often misunderstood.

The while SSL is the popular name (and as it was once known) and HTTPS usually is the way users sees it (as part of a URL in a browser) – the correct name is TLS a short for Transport Layer Security.

The TLS provides point-to-point security between the browser and and server. It makes certain no-one can see the traffic (/data) sent between the two parties. Simply put, it provide a secure tunnel/pipe, where anyone can’t listen in. Almost everyone understand TLS to this point.

Many users however thinks it provides more than this. That TLS provides protection from malware infection, voids dangers of cross-site scripting attacks and other dangers of the web, and TLS does not provide any of the sorts.

While the security it provides is good and solid, it is important to understand the scope and purpose of TLS/SSL, it’s often an important part of the security infrastructure of a web application, but only part of it.

Function names as signaling

In most web applications there’s a host of functions (or methods if speaking in the object-oriented world). It’s widely recognized, that it’s probably a good idea to name them something, which may suggest the purpose or functionality of what the function is doing, but often developers seem to fail at making a stringent naming convention. Before starting on your next big development adventure, here are a three suggested rules for naming functions.

1. It’s more important to have a suggestive name, than a short one.

Never call a function something short but meaningless. Instead use CamelCase and make a sentence suggesting what the function does.

  • Bad examples found in live code: “process”, “fixit”, “cleanup”.
  • Good examples: “saveToDatabase”, “convertIpnumberToDomainName”, “calculateTotalPricing”.

2. Use prefixes on functions

Reserve common names (more if you like) for specific type of functions. Here are a few suggested rules:

  • “get”-functions should always retrieve and return data – never print data.
  • “print”-functions shoudl always print data to “standard out”.
  • “set”-functions should ways set data to an object (and choose if “set” also saves data or not).
  • “save”-functions (if set-functions doesn’t save properties) saves all current properties to the persistent storage (usually database).

3. Reuse data model objects in function names

If you’re data model (or object model) already contains names of entities, reuse these in function names. If a table is named “Travel”, call the function “saveTravelRecord”, Not just “saveDataRecord”.
Make consistent use of the same names, field names, properties and other entities found in the application. Using the same name for the same object all across the application, may seem obvious, but somehow developers seem to find slightly different names for the same object again and again.

While the three above tips may seem simple, do check your code and see how many places they are broken. I’ve seen countless times, and getting it right from the beginning would have cost a small effort, refactoring the code years later is a much bigger effort.

Bread crumbs in version control

I’m sorry but sometimes I really don’t get why even seasoned developers doesn’t learn the art of the commit message in version control system. All too often I’ve come across check-ins where the entire commit message just reads “bugfix”, “change”, “oops” or something just as mindless.

The effort of writing a useful message compared to the potential benefit seems to be one the best ratios – but of course the pay-back is usually some time away – too bad. Once you work on the same code for years – or even better inherit code from others, you’ll quickly learn to appreciate anyone who used more than 10 seconds on composing a thoughtful message for the future.

Here are 3 rules you should always, always obey when committing to a version control system.

Always leave a reference to the issue/bug tracking system.

All professional development uses some sort of issue tracking system, to keep track of bugs, new features and other changes to the system. The issue tracking system should always be able to tell who asked for a change, why it was asked for and what considerations was made before the code change. By leaving a reference to the issue tracker, it’s often much easier to get “the big picture” if the change need to be changed years later. To make sure you get it in, just write “Bug #number#: “ as the initial part of the commit message.

Don’t write what, write why

Don’t write it’s a bug fix – most people will know it from look either at the code or in the issue tracking system (see point 1 above), rather write why it fixes the issue (“New check to check for missing parameters”, “Now handles no search result from db correct” – not just “bugfix”).

Keep it brief.

Log messages are not a place to store documentation, user guides or any other important information. You can assume it’s the future you (or another future fellow developer) who will look at the code and try to make sense of it. Think of this, when writing the message – it’s not for the project manager, it’s not for the end-users – it’s for a developer doing maintenance work on the code in the future.

PHP best practice: Function Parameters

I’ve been developing web applications for some years now, and while I make no claims to being the world greatest developer, I do figure, that I do have some solid experience which may help others – or at least encourage thoughts and discussion. This is the first in a series of posts, and while it may be from a PHP developers point of view, it may applicable to other programming languages, and maybe even beyond web applications. Here are my four tips on function parameters.

Always have a default value on all parameters

Functions parameters are often used as input to SQL queries, calling webservices or computations. Null or non-existing values often tend to break these things and throws horrible messages to the end-user.

While the parts of the program using your function always should provide proper values, laziness, oversights or unexpected scenarios, may prove it not to be the case. If at all possible, always try to provide default values on all parameters to a function – and if you really can’t make sure it’s handled gracefully.

Choose reasonable defaults

When providing default values, don’t choose extremes. If you’re browsing in a list of usernames, don’t use a (pure) wildcard as default value – use an “A” to list all users starting with the letter A. If you’re function allows a limit on the number of rows returned form a database query (say for paging purposes), set the default to 10, 20 or some other low number, don’t go for worst case scenarios like 9999, or 999999.

If the developer using the function needs plenty of rows, it’s easy to pass a specific value, and if the developer forgets to specify the number of rows, expected, they get a reasonable result, which may help them to ask for more (if actually needed).

Always sanitize input

Even though a given function naturally only will be used with valid input and so on, every function should take steps to secure them selves.
One of the most basic steps is to make sure all input is sanitized. Protecting your function from making SQL injection threats or other security issues, is not the responsibility of the places utilizing the function, but the responsibility of the function it self, and thus it should take steps to make sure it doesn’t introduce security issues.

As basic validation of simple input parameters, look at the ctype functions in PHP. If you can always try to validate against a whitelist (which characters are allowed) instead of blacklists (these characters are not allowed) as missing things which may introduce issues in a black list is harder, than allowing what you expect, to pass through.

Accept an array of key value pairs

If a simple function accepts a single or two parameters, they may be passed as regular parameters, but once the list of possible parameters starts to grow, changing it a single parameter – which is an array with key/value-pairs, seems to be a much more solid long-term solution on keeping the interface developer friendly. Sure you can have endless lists of 10-15 parameters, but if you have default values on the first 14 values and just need to change the last, the code ought to be much more clean by being able to pass an array with the single key/value-pair needed to be changed from the default value.

That was the first four tips on function parameters. More on PHP and Security.

Roaming todo-lists

I’ve been exploring todo lists for a while, but so far not found the ideal solution. I did however get a mighty step closer after Schack told me about a firefox plugin called Quickfox Notes.

Before introducing Quickfox notes, let me spend a second on my daily workflow in broad terms. I usually have Firefox running 8+ hours a day. Either browsing the web, doing web development or just by habit. I work on several machines – A few Linux laptops and an iMac at home. As I use several machines, I’ve been a huge fan of bookmark synchronization. I tried Mozilla Weave for a while, but their lack of PowerPC support (on an other Mac), eventually made me switch to FoxMarks – which is now called Xmarks. Xmarks has worked flawless since day one, and it’s one of the very first plugins I always install along with firefox on any machine I use.

Quickfox Notes is a way to store notes in the Bookmark-engine in firefox. It sounds odd, but it works really well. There aren’t any fancy formatting options – think notepad – but to keep a basic todo-list, code samples and other short texts, it works quite well. The killer feature of Quickfox is the combination with roaming (or syncing) bookmarks – If Quickfox Notes is installed along with Xmarks (, Weave or any other bookmark syncing dervice), it provides you with note-syncing too.

Build-in time bombs

I’ve been refactoring and refactoring some old code, and it’s kind of odd what short-cuts (or even time bombs), you’ll find in code, which apparently wasn’t supposed to live on for years.
In a now retired CMS system, we had an issue every new year, when some kind of bug would reset all “schedules” for upcoming stories and content. No-one ever got around to fix it, as the system was soon to be decommissioned – but sadly the bug did survive a few years anyway.

These days, I’m was working in the system, which came to replace the broken system from before. Here’s another odd thing – It was apparently hard coded into the editor in the backend, that stories need to have a “published date” between 1996 and 2011. As there really isn’t any documentation and the original developer has left the company, it’s hard to know why it was made so. While there probably was a reason, it’s lost by now.

 <select name="year" size="1" style="width:55px;" title="Year">
 <?php
   for ($i = 1996; $i < 2011; $i++) {
       printf("<option value=\"%1\$d\"%2\$s>%1\$d</option>",$i,($year == $i) ? " selected" : "");
   }
   ?>
</select>

We fixed it by making the latest “published date” go between 1996 and current year plus one.

While it was an odd thing, I’m surely glad that we from time to time do some sort of maintenance of old code – even while it seems to work perfectly. It’s far from the only bad thing we found, and while most people worry mainly about new code, sometimes you should also remember the old stuff.

Better but Broken

Working with application development – either on the web, on the desktop or any other place – is often quite interesting. When making new releases features are added, changed – or in rare cases removed.

As a developer – or “software product manager” – it must be an interesting challenge to keep up with the users and the market to capture the features and changes to a product, which will make it better from release to release.

There are probably many ways to try to keep up – by doing research and by listening to user feedback seems to be two obvious choices, but I’m sure, there are many others. Some, I’m sure is also just a gut feeling of what might be cool new features. If you’re good – and now the users, the market and the competitors, you’re making steady progress.

Yet sometimes you miss. The slow adoption rate of Microsoft Vista might be a sign of a very public miss.

It doesn’t have to be a big miss, to chase a user away.

picture-1This weekend it happened to one of my favorite iPod Touch games – Tap Defense was upgraded to version 2.0 – and while most of the updates probably are great, there’s one little detail, which probably ensured I’ll rarely play it again (unless I find a way to fix it).

I used to play Tap Defense a lot while listening to Audiobooks and Podcasts. The new version has been updated with sound effects and music – and now the podcast or audiobook goes away (pauses) when the game is launched.

I’m sure TapJoy, developers of the Tap Defense game, are proud of their new sounds, but if I need to choose between the game and my listening to podcasts, the game looses. Please bring the ability to keep listening to what every the iPod plays, back in version 2.1.

The art of the commit (in version management)

Most developers (and certainly professional shops) working with software- or webdevelopment has understood the ideas behind sourcecode version management – no matter if they choose to use cvs, subversion, git or any of the other fine systems available. How developers use these systems, can provide an easy insight into who is the dummy, the average and the great developer.

When to commit

One of the first distinguishing signs is what they commit – is the version management system used as a backup tool or as a version tracking tool. Some seem to think, you should end the day by committing all your sourcecode (no matter which state it’s in). This is really bad sign. Others commit whenever a new file is finished and thought ready to use – which is slightly better. Others again commit once – just before a new release – and has the commit contain each and every change since last release.

In my world a commit should contain a complete new feature across all the files changed to make the new feature. The commit should preferably only address one change (a new functionality or a changed feature).

The commit message

Another way to spot bad habits is in the commit message. Is there a commit message at all? – if not, it’s a bad sign. Almost as bad are meaningless comments, which may come in all sort of varieties – “work in progress”, “bugfix”, “update”, “foobar”. I’m sure they make sense to the developer at the time of committing them, but hardly 6 months later, when browsing the logs and wondering why a certain change was made.

A less common bad commit habit is the “book style” – where the comment either contain a delta of the changed lines (literally or as a description) or the length of the comment is a small story explaining the reason for the change, why it was made the way it was and on and on.

I’d any day prefer seeing a reference to a bug/ feature tracking system (bugzilla, trac or anything like it), and a brief summary of the change in a 140 characters a less.

Security can be easy

It’s often the case that security is an inconvenience and gets in the way of usability and ease of use. There are exceptions though and for a number of weeks I’ve been playing with the Yubikey (thanks to Schack) from Yubico.

It’s a small device, which plugs into a USB port, and to the computer acts as a keyboard. It has some advanced security build-in with the ability to generate one-time verifiable passwords, but is incredible easy to use – plug it into the USB port and press the single button when you need to sign in to services supporting the Yubikey.

I’ve been useing it with OpenID sign-ins and WordPress logins, and it’s worked flawless everytime. The only important thing is to remember the Yubikey – without the little hardware token, you’re lost. If you need a secure sign-in solution, listen to security now to get the technology explained and contact Yubico, it’s seems to be as affordable as it is easy to use (and no, the post isn’t paid or sponsored, nor do I know anyone at Yubico).