Feature

Digg This!

We've all seen it: the dreaded "Error Occurred While Processing Request," which is the headline above a normal CF error message. As developers, of course, we relish the detail it offers: the CF error message, the line number and actual line of code in error, the name and path of the template in which it occurred, and so on. But is this the best thing to show our end users?

Probably not. What should they do with that information? Do they care about these details? Could a hacker use them for unintended purposes? And perhaps most important, how do you even know the error has occurred?

Several features - some old, some new in 4.5, but in either case often missed and misunderstood - can dramatically improve error handling in ColdFusion. In this series of articles I'll cover the basic solutions, CFTRY/CFCATCH, CFERROR (three forms of it) and Site Wide Error Handling, which may be new to you.

In this issue, though, we'll focus on some administrator settings that you may not have considered and that may be quite important to any effective error-handling strategy, depending on the other error-handling choices you make. I'll show how you can reduce the level of detail offered in error messages, as well as improve the ease with which errors may be reported to you when they occur. Along the way I'm confident even the most experienced CF coder will learn a thing or two as some aspects of these features are poorly documented and not obvious.

I'll discuss those other error-handling choices (CFTRY/CFCATCH, CFERROR, and Site Wide Error Handling) in forthcoming issues of CFDJ, and at the end I'll offer a clear list of things you should be doing to better handle errors in your applications.

By applying even one of these solutions, with just a few minutes work (or seconds, in some cases) you could dramatically improve not only your end users' experience, but also the security of your site and your awareness of errors that occur in your applications.

That Lovable, If Pesky, Error Message
The standard CF error message is a delight to the CF developer, with all that great detail. And if it's a SQL error, we even see the database error message, the name of the datasource in error and the SQL statement that was attempted. This is just great for debugging. An example is shown in Figure 1.

Clearly, the creators of CF were developers at heart and realized we'd need to see that info to solve problems. Quick Tip: When you get an error, do you jump back into the code and try to find and fix it? Most developers seem to...and fail to take full advantage of the text of the message. In some cases, though (see Figure 1), what's wrong isn't always obvious.

Even then, if you hop back into the code to scroll around looking for the line of code in error, you're missing a useful shortcut. Notice the line number that's offered (line 79 in this example). In Studio, type CTRL-G (or Edit>GoTo Line) to jump to that line of code. It's not a perfect solution, however; if you have any CFINCLUDEs above the line in error, the numbers in the Studio won't be in sync with the one reported in the error.

This detail is great for developers, but when you move your code to a production environment or, more simply, when an end user visits the site, is that error message an appropriate thing to offer them?

Is It the Right Thing for End Users?
There are several problems with letting users see an error message. First, of course, there's the compromise such errors make to your otherwise elegant user interface. How does it look when they go from your site's consistently blue background to the plain white CF error message page? And what are they going to do with this information? And again, how do you know the error has occurred for your users? Do you simply wait for a call and report it? And have you considered the security risks of showing the physical path of your templates and the SQL datasource name and statements of failed queries in this error message to users?

If you're like many CF developers, these are things you probably haven't thought about, or simply didn't know how to solve. As of Release 4.5, there are a host of options you can consider to limit, modify or hide the error message users see. You can even arrange to log the errors in a database and/or send your developers an e-mail indicating that an error has occurred.

But these enhancements generally require programming changes. We want to start off with some quick changes that can be made to assist the user in informing you that an error has occurred, as well as limiting what information is displayed.

Administrator Configuration Changes
In this article we'll consider three changes that can be made in the CF Administrator. They'll have an important impact on the information presented (or hidden) in the traditional CF error message.

Subsequent issues will cover modifying or completely hiding the display of the message as well as logging/e-mailing it to you automatically, with new "error-handling templates."

But even with those in place if you have them (or until we cover them next month), the changes discussed below have benefits. They'll improve both the ease of users reporting an error as well as the security of your site - especially if you won't be implementing error-handling templates.

The issues we'll cover are setting the administrator e-mail, hiding the SQL and datasource name for query errors, and hiding the template path to the template in error. Even if you think you understand these options, there's more to them than is documented. Let's look at them in detail.

Defining the Administrator E-Mail Error-Handling Address
Some experienced developers may be surprised by my pointing this out, but it's one of the simplest improvements you can make, in the right circumstances, and it's easily implemented.

In the CF Administrator there's a place where you can define the administrator e-mail address for the server:

• Take the "settings" link under the Logging area on the left nav bar.
• Enter an e-mail address that should receive e-mails sent by users choosing an option that will be presented to them to send such messages.

Entering this address will from then on cause an additional line of display to be shown on the standard CF error page (the traditional unformatted one), at the bottom of the screen:

Please inform the site administrator that this error has occurred (be sure to include the contents of this page in your message to the administrator).

The "site administrator" link will now hold a hyperlink that when clicked will indicate to the browser that a mail message should be created to be sent to the e-mail address specified in that Administrator setting. (If the user's browser and e-mail client are properly configured to respond to such e-mail hyperlinks, the client's e-mail program will launch an e-mail message to the specified address - and the user can choose to fill in the subject and body of the message.)

Of course, we still have to hope they pay attention to the error message that states they should "include the contents of this page" in the message they send. And it's important to note that this doesn't mean that the "administrator e-mail" address will receive notification of every error that occurs - only when end users click the link offered in that message above. That's something we'll enable in the next issue.

Not Enough, But a Good First Step
This still doesn't solve the other problems of the less-than-attractive interface of the error message or getting an automatic notification. But it's a step in the right direction and, unless you're in a shared server environment where no one person is a suitable recipient of all notifications about error messages, it's probably the first thing you ought to do. (Just be sure to change that administrator setting should that person ever change or leave, lest messages be sent to someone who'll never get them.)

It's also useful when you do use site-wide error handling, as it becomes a variable you can refer to in the site-wide error template, covered next month.

Hiding the SQL and Datasource Name, and Template Path
I've already mentioned the potential security risk of showing the end user such details as the path to the template in error and the SQL code and datasource name in failed queries. In the next article I'll show how you can hide the entire error message from the user, so this point about hiding certain details of the message may become moot if you apply the other techniques. But it's important to understand, especially if you're not currently aware of the issue and may not soon implement those other techniques.

The Risk
Let's look closely at the information shown in the normal CF error message, focusing just on the SQL and Datasource name of a failed query, and the path to the template in error (see Figure 1).

Could someone take advantage of knowing your Datasource name (SomeDSN, in the example) and the SQL code of the failed queries? Or the template path (C:\INETPUB\WWWROOT\SOMEDIR\) to the page in error?

Well, perhaps not if they're just a user of your Web site. Of course, if such a user could break in, they could certainly take advantage of the information. But such break-ins are unlikely, or at least well beyond the scope of this article.

But what if you're on a shared Web server with others who aren't related to your application but can also put CF code on the server in other directories? This is certainly an issue in a commercially hosted Web site on a server shared by many users. It's also a possible concern for users on a corporate Web site having multiple unrelated applications. (One solution to this problem is to use CF's Advanced Security, but this isn't a trivial exercise and is beyond the scope of this article.)

As for the SQL and Datasource Name, if someone can place CF code on the same server as you, have you considered the risk to your data if he or she knew the datasource name for your database? What's to stop someone from running a query against your database? If you're not password protecting your database, any CF template that's running on that same CF server can write a query against your datasource. Password protecting the file may be trivial or challenging in your environment, but explaining it is a subject for another article.

There is yet another risk, as described in Allaire Security Bulletins ASB99-04 and ASB99-09. It's possible in some situations (if not otherwise protected using the suggestions in the bulletins) for a Web visitor to append to the end of a URL (in certain rather unusual situations) extra SQL commands to be executed against your database. This isn't really a CF bug but rather a database driver issue.

In both these cases, if someone can see the SQL statements (including table and column names) shown in an error message, that makes it all the easier to take advantage of any security hole or weaknesses in your environment. So let's hide that information.

Hiding the SQL and Datasource Name in Query Errors
The good news is that it's easy to stop that information from showing in the standard error message (or the one available for display as a variable in one of the error-handling template approaches, discussed in the next issue). It's just a simple tick of a checkbox in the CF Administrator.

It may not be so easy to find, however. It's presented along with server-side debugging control options:

• Take the "debugging" link under the Miscellaneous area on the left nav bar.
• Make sure "Show SQL and data source name" is unchecked.

Doing this will reduce the amount of detail in the message above by removing the lines:

SQL = "select * from jobs where jobs.companyid = 499 and jobs.composite_ad_yn <> 1 and jobs.jobtitleid = jobtitles.jobtitleid and jobs.cityid = val_cities.cityid order by stateid,city, jobtitle, date_posted desc" Data Source = "SomeDSN"

That's another step in the right direction.
Now you might be worried about the loss of this useful information as a developer, but there's good news.

Interesting Behavior That May Confuse You
The text explaining this option in the Administrator screen suggests that it controls display, not only of the Datasource name but the SQL statement in error as well. You may find, however, that after doing this you'll still see the SQL statement in error. Is the feature broken? Will end users still see the SQL statement in error? That depends.

Although it's not documented anywhere, this option behaves in an interesting way, and it explains why this option is on the debugging options page. A user who can see the server-side debugging information will always see the SQL statement in error, regardless of whether the "show SQL and datasource name" is turned off.

This is a nice feature for developers as it gives them the detail they need. It's likely that you don't show end users the debugging information, so this makes it really safe to turn off the display of the SQL statement. Those who shouldn't see it won't, while those who should, will.

Hiding the Template Path
The security concerns don't stop there. Remember that display in the error message of the physical path to the template in error? That can also be used by hackers, or simply by others not associated with your project but located on the same server. A few tags available in CF, such as CFFILE and CFCONTENT, allow access to any file in the CF server.

The error occurred while processing an element with a general identifier of (CFQUERY), occupying document position (26:5) to (26:59).

If someone running code on your server (again, someone who has access to the server or, less likely, someone who's broken in) knows where your code resides, that person can use those tags to grab your source code...or possibly your database.

There are two broader solutions to that problem: one is to restrict access to those tags in the Administrator, which is an option under "Basic Security." Or you can configure Advanced Security, mentioned previously, to protect directories from access by other developers on the same server.

Beyond those security approaches, you can also lessen the risk caused by error messages showing the template path by simply preventing its display in the standard CF error message. Like the "SQL and Datasource Name" option, it too is embedded, curiously, among the server-side debugging control options:

• Take the "debugging" link under the Miscellaneous area on the left nav bar.
• Make sure "Display the template path in error messages" is unchecked.

Doing this, along with the SQL and Datasource Name option, will reduce the message detail by changing the last line in the message to:

The specific sequence of files included or processed is:
C:\inetpub\wwwroot\somedir\sometemplate.cfm

Additional Observations
Sadly, this option doesn't respond the way the SQL and Datasource Name option does: even if you're authorized to see server-side debugging information, once this option is turned on, the template name and path will no longer be displayed in error messages. This will make it a little harder for a developer to determine a template in error.

If you have development and production environments, it's certainly worth considering whether you really want to use this option to hide the template path in the development environment.

Some errors (unless otherwise handled by error-handling strategies to be discussed in the next issue) will still show the template path anyway. Compilation errors are an example. Consider this example: turn off the display of the template path and run a template with the code:

Cfif></cfif>

This compilation error will display the complete path in the error message, after the details about the compilation error itself, as in:

This doesn't happen in all classes of errors, but it's something to keep in mind.

Conclusion
We've covered a lot of ground, and hopefully you've learned some things about configuring the Administrator to improve error handling.

Next month I'll explain further the opportunity to have even greater control over the display of errors, or hide them entirely and simply e-mail them automatically to a support person with no interaction by the user, or perhaps even log them to a database. I'll provide two of the three alternatives: Site Wide Error Handling (new to 4.5) and application-level error handling (which has changed significantly in 4.5). In the final part I'll cover CFTRY and CFCATCH, which offer even finer levels of control over error handling within your code.

As for the recommendations to take from this article, consider the following as a summary of the Administrator changes available to you:

• Set the Administrator e-mail address (if you're on a server where all the applications are related and one person is appropriately ready to handle all such messages).
• Turn off the display of the Datasource Name and SQL for queries in error, and the template path to the template in error, in anything other than a pure testing/development environment.

As for some of the security best practices we alluded to:

• Password protect your databases (even in Access) so users running code on a shared server with you need more than just the datasource name and knowledge of your tables and column names to access your data.
• Read the two Allaire security bulletins about further protecting your data from end users who might be able to take advantage of certain security issues in some database drivers and with some templates.
• Consider the "Tag Restriction" options in the Administrator to further prevent the likelihood of abuse among unrelated developers on a shared server.
• Set the Administrator debugging options to prevent server-side debug information from showing to your users, which allows the hide "SQL and Datasource Name" option described above to indeed hide the SQL in error.

For all these options, see the Allaire documentation for more information. All the administrator configuration options presented in this article are discussed in the manual Administering ColdFusion Server.