Protect Yourself

Submitted by Chris Norloff, [e-mail]

Protect yourself, your application, and your server. But from what? Protect from users, code errors, database errors, and network errors. This is to keep your application running, to please your users and customer, and to ensure that your application is not unfairly blamed for downtime.

Coding

The most important protection is to code to eliminate errors: Test variables for existence before using them, use CFPARAM for default values, and include code to handle data that is not what it "should" be. Explicitly account for all conditions when using conditionals like CFIF and CFSWITCH. Second most important is to place CFTRY/CFCATCH blocks around all code to catch errors. Use CFERROR for errors not caught by CFCATCH. The ColdFusion server can't be serving up application pages if it's spending time serving up errors.

Make your error messages as specific as possible to inform your users, particularly if there's something they can do (such as making a reduced request if the page has timed out). Nobody likes generic error messages. Provide debug information for programmers: We provide all CFCATCH-scoped or error-scoped information. We use HTML comments <!-- --> in the error page to display programmer-oriented debug information. This way, the user does not see it, but the programmer can use View, Source. This is very handy for machines for which we can't access the code directly. Log all handled errors using CFFILE and review the logs regularly.

Other considerations for the application are to prevent users from pressing submit buttons multiple times, to use CFQUERYPARAM to protect the database from bad data, and to protect the application from commands stored as data. Can your application respond if the database is down? Don't let a database or database-connectivity problem appear to be a ColdFusion problem.

We also place test files in the application so that we can easily determine what services are running, particularly on a production machine for which we might not have administrator access. We use a basic HTML file, a basic CFM file, and a CFML file with a database query.

Testing

We review the logs from the quality assurance server after every new release from development. All errors have a test problem report written. Code should be error-free when it leaves the development server. We use PVCS Tracker to automate the communication and tracking of problem reports.

These ideas and similar approaches will make your application more robust and will give you fewer headaches from downtime and performance problems.