Avoid those "hidden" features

I've said more than once that folks should avoid using hidden, undocumented features in ColdFusion. This warning applies especially to the ServiceFactory. Did you know that in ColdFusion 8 you can restrict access to the factory? In the settings page there is a new option:

Disable access to internal ColdFusion Java components
Disables the ability for CFML code to access and create Java objects that are part of the internal ColdFusion implementation. This prevents an unauthenticated CFML template from reading or modifying administration and configuration information for this server.

So what happens when this is enabled? Consider this simple code:

<cfset monitor = createObject("java", "coldfusion.runtime.RequestMonitor") />

With the above option disabled, it runs fine, but when turned on, you will get:

Permission denied for creating Java object: coldfusion.runtime.RequestMonitor.

Access to Java objects in the ColdFusion package has been disabled by the administrator.

So just keep it in mind when developing. I won't deny that I've used these internal objects myself in the past, but now I avoid them like the plague. Almost anything you need (almost) is available via the Admin API anyway.

Comments (9) Aug 28, 2007 8:19 AM Views: 1556

Comments

[Add Comment]
While I agree with your sentiment, I don't agree with the concept really. Even documented tags get depreciated and changed between versions. CFCHART and CFGRAPH for example.

Instead we should be advocates for better coding practices. For example instead of saying 'don't use the admin objects', you should instead build version specific libraries for using the admin api and alike:

lib_cfusion.cfc -> the library you use to run coldfusion specific functions
lib_bdragon.cfc -> the library you use to run bd specific functions
lib_cfusion_7.cfc -> uses the coldfusion 7 libraries
lib_cfusion_8.cfc -> uses the coldfusion 8 libraries
lib_cfusion_8_admin.cfc - version 8 admin api library.



etc

This way if the api changes all you need to do is create a cfc for the new version and pass the version as part of the arguments for each function.

This is the way a lot of javascript libraries work, why not implement it in coldfusion?
# Posted By Chris Dawes | 8/28/07 10:44 PM
I should have mentioned that the lib_cfusion.cfc is extended by the lib_cfusion_8.cfc and lib_cfusion_8.cfc is extended by lib_cfusion_8_admin.cfc

lib_cfusion.cfc
|_ lib_cfusion_8.cfc
. |_ lib_cfusion_8_admin.cfm

You could just have two levels really, it's up to you. The functions used are in the lib_cfusion.cfc : eg <ctmmffdump> cfscript replacement - which has difference attributes from v7 to v8.

I'll post more on my blog later today (AU time)
# Posted By Chris Dawes | 8/28/07 10:48 PM
I don't quite think we are on the same page here. I never said to not use documented tags. I don't think there is anything wrong with that. Deprecated tags should be avoided, but they still work. I'm talking about stuff that is NOT documented and is not guaranteed to work. Shoot - parameterExists still works and has been deprecated for over 5 years.

This has nothing to do with coding practices. It's really about just following the "rules", the rules being the docs.

You are basically saying it IS ok to use the admin objects, but only if you run them in an environment that matches the CF version. I say it is never ok and should be voided. Period.
# Posted By Raymond Camden | 8/29/07 5:27 AM
*cough*
Don't know what you're talking about Ray....

*hides under a rock*

;o)
# Posted By Mark Mandel | 8/29/07 5:53 PM
I wanted to let you know that ADDT, which was interaktonline MXKollection(a add on MXI that adobe now sells) uses ServiceFactory in their Login functions, under the KT_functions.inc.cfm and is becoming a huge pain for people that move up to cf8 in the shared environments where this option is disabled. This completely screws up all applications that are created with ADDT.
# Posted By Link Mckinney | 2/3/08 10:42 PM
Here's another little tidbit. I'm finally getting to play with Flex and ran the main sample application Adobe provides to show connectivity to a database via Coldfusion. So the application works great on my localhost but as soon as I try to put it up on my shared host I get:

Permission denied for creating Java object: coldfusion.server.ServiceFactory.
Access to Java objects in the ColdFusion package has been disabled by the administrator.

All because of the following line of code:

<cfset factory = createObject( "java", "coldfusion.server.ServiceFactory" )>

Now, mind you, this is the first sample application you will get from Adobe regarding database connectivity between Flex 3 and Coldfusion and most places, it won't run. Not to mention, my host says that it supports all tags except for CFExecute and CFRegistry which would lead you to believe CFObject will work for any circumstances.
# Posted By Brad Melendy | 4/1/08 6:30 PM
Brad, please email me off blog (use my contact form). I know the guys who worked on this code and I can hook up with them.
# Posted By Raymond Camden | 4/1/08 7:48 PM
Well, I was WRONG. Turns out that in my haste of pushing code to my shared host, I left the datasource incorrectly named. My pointing fingers at the CFC was due to my inability to hit the CFC with a direct web request like this:

http://brad.melendy.com/projects/flex/DataTest4/em...

This generates an error on my shared host but not on my localhost.

However, it works great when you hit the Flex app:

http://brad.melendy.com/projects/flex/DataTest4/Da...

So fooie on me. I'm just glad it works. :-)
# Posted By Brad Melendy | 4/2/08 2:30 PM
Glad you got it. I noticed some missing var statements in the CFC. I've pinged my contact about getting them fixed. While not critical, Adobe should try to always provide good code.
# Posted By Raymond Camden | 4/2/08 2:36 PM
[Add Comment]