Gateways - A Design Concept

[swatts]

Hello Error Destroyers

When writing software you often have to take data from a human and convert, parse, transmit or store it on a machine. It often transpires that humans are really incompatible with computers! They are flakey, vague, illiterate, moody, impatient, bored, rushed and/or inaccurate.

You need to bear this in mind when taking data from them.

This example is how most software I have seen looks. Quite a lot of what I've written too!

 

What's wrong with that I hear you ask?

Well try entering O'Reilly into an SQL Statement or a SELECT user query with ' OR 1=1 as its recipient.

Or you could offer Users the freedom to set their own channel names and they include control characters, an action that will destroy TDMS files (a bug that took me a LONG time to find and fix!)

Here's some example of possible recipients of dangerous data.

• Storing data in databases and SQL
• Storing data in formatted files (TDMS, JSON, HTML, XML)
• Transmitting data (UDP, Serial (XON/XOFF))

Here's what we need to consider when dealing with human enter data.

 I've tried various methods for policing and making data safe. You can police at the dialog/data entry stage.

The vi is called  "Is Name Multiplatform.vi" and can be found in ..\vi.lib\Utility\libraryn.llb. Check out Darren Nattingers Weekly Nugget.

Another way that we often use is to make it safe before it is used, as below.

The innards of which looks like this.

Obviously it will need making unsafe by return, this is just the reverse of the above.

This is especially useful when users like apostrophes and single speech marks, SQL hates them!

The moral of this story therefore is if you have human entry whack in a post-condition check after entry or a pre-condition check prior to entry. It will save you some headaches!

Lots of Love

Steve