ColdFusion 9's new Application variables

This post is more than 2 years old.

ColdFusion 9 adds a few new settings options for your Application.cfc file. Some are documented, some are not. You can find the documentation for these variables here. Here is a quick run down of what was added.

Edited: I'm finding more missing keys, so I've updated the article.

  • datasource: Allows you to specify a default datasource for all queries in your application. This one is missing from the list which is a bit surprising, but I'm sure it will be fixed by the doc team. Ben Nadel just covered this as did Forta a few days ago.
  • ormenabled: A boolean that determines if ORM is turned on for the application.
  • ormsettings: A structure that specifies how ORM is enabled for the application.
  • serverSideFormValidation: Allows you to disable server side validation. To be clear, it doesn't mean that it will block all server side validation, but rather, the old school, built in, server side validation based on form field names. I talked about this more last night.
  • smtpServer: As you know, cfmail tags will default to the server specified in the Administrator unless you override them at the tag level. This new attribute lets you override it at the application level. Unfortunately, it isn't working for me yet. I specified it, then tried to run a mail tag, and was told that I had not specified a mail server at the admin or tag level. I think it is safe to assume this will work though and it's a nice addition.
  • timeout: This allows you to set an application-wide value for your request timeout. Previously this would rely on the Admin setting, or the value in cfsetting. Interestigly the docs say this overrides the cfsetting tag. I would think the cfsetting tag would take priority. I did a quick test, and cfsetting did take priority, which is a good thing, even if it's a doc bug.
  • debugipaddress: Allows you to specify a list of IP addresses to enable debugging. Woot! Now folks on a shared host can enable debugging without needing CF Admin access!
  • enablerobustexception: Allows you to turn on robust exception handling. Nice... and a bit scary. In general, this should never be enabled on a production server. But if you need it, and again, don't have CF Admin access, this will allow you to enable it for your application.
  • googlemapkey: Allows you to define a Google Map's API key for all cfmap tags in the application. Useful if you do not want to specify it at the server or page level.
Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Ben Nadel posted on 7/13/2009 at 7:00 PM

serverSideFormValidation - Wooohooo!!

Comment 2 by Brian Swartzfager posted on 7/13/2009 at 7:03 PM

"debugipaddress": oooh, that will be nice!

Comment 3 by Ben Doom posted on 7/14/2009 at 3:20 AM

It's really too bad that enablerobustexception isn't on the request level -- then it could be controlled by IP, by comparing to cgi.host_header. In fact, you could pretty easily set it up so that recognized IPs get robustexceptions, and unrecognized IPs get cferror.

Maybe I'll just have to make that suggestion for CF10.

Comment 4 by Raymond Camden posted on 7/14/2009 at 7:48 AM

You can actually:

if(structkeyexists(url,"ok")) this.enablerobustexception = true;
else this.enablerobustexception = false;

This let me pass ok=1 in the URL to see the full info.

Comment 5 by Christoph Schmitz posted on 7/14/2009 at 12:36 PM


is there a way to override the Application setting of enablerobustexception? Robust exception information is considered a security risk and I can imagine that some providers would be glad if they could disable this.


Comment 6 by Raymond Camden posted on 7/14/2009 at 4:10 PM

I believe the application setting will override it. You would need to file an ER for that. Personally I disagree with you - not that it's a risk, but that the Admin should take priority. I think the application should 'win' in cases like this (normally anyway).

Comment 7 by Ben Doom posted on 7/14/2009 at 5:46 PM

If the enablerobustexception flag is thrown on an application level, won't turning it on/off based on the client's IP run a risk of having race conditions?

If you visit my site, and have them turned off, then I do, and have them turned on, then you error, you'll see the error.

I realize that that is a pretty minor risk, but still....

Comment 8 by Raymond Camden posted on 7/14/2009 at 5:48 PM

While it is an Application setting, it is per request, so how would it matter? And as it stands, this ONLY has an impact on 'naked' errors that you don't handle. I'd assume in production you always use onError anyway which kinda makes the whole thing unnecessary really. onError will ALWAYS have the full exception object, period.

Comment 9 by Hemant posted on 8/5/2009 at 7:05 PM

A small correction - debugipaddresses should be debuggingipaddresses.

Comment 10 by Raymond Camden posted on 8/5/2009 at 10:17 PM

Hemant - the docs are wrong for this then. I was wrong when I copied it too. The docs say debugipaddress (singular). Will you handle filing a documentation bug?

Comment 11 by Hemant posted on 8/6/2009 at 7:02 AM

I shall log a doc bug.