ColdFusion Muse

ColdFusion Job Openings - Alive and Well

Yes it's true! CF Webtools is looking yet again for qualified advanced developers. I know seeing my plaintive cry for developers might get old for long time readers. I would beg the courts indulgence and only ask that you remember my constant nagging for you to send me your resume when the lean years come (as they almost always do). Remember, our jobs are full time, telecommute with competitive salary and benefits. We have a talented engaging staff, interesting work and a chance to stretch your skill set. If you are an advanced or aspiring advanced ColdFusion programmer we might be a great fit for you! Here is the rest of the Muse' blurb:

---

Here's what we are looking for. If you:

• Take ownership of a problem.
• Think around all angles of a problem for all possible solutions
• Love the tech community as a place to engage and learn.
• Have evolved skills in an eclectic mix of technologies and like to learn new ones.
• Can explain technical concepts to non-technical folks.
• Know how to honor non-technical people for their own skills and expertise.
• Can laugh, chortle, guffaw and otherwise split a gut with a group of insanely funny people - without the need to put anyone down.
• Are anxious to be a part of a close knit team who encourages and believes in you.

Then by all means you are who we are looking for. For more info on what it takes to be a CFWT consultant check out my post on You Might be a Muse All-Star.

Frequently Asked Questions

• Do you allow telecommuting? Yes all our development positions are full-time remote positions.
• What sort of dev environment can I expect? We are en eclipse shop and rely on SVN, Jenkins, and an agile like approach to development. Having said that, as an outsource development company we frequently integrate with external teams. That means you can't always predict everything about the approach for the project you are working on.
• What Industries are you working in? We have sites we develop and maintain in the Financial sector (stocks, options, commodities, retirement planning and management etc.), Insurance, Medical, Pharmaceutical, retail sales, real estate, etc. We have a very broad client list.
• Will I get to meet the Muse? Yes of course... you'll be sick of me inside of two weeks.
• Do you use frameworks? Yes - all of them all the way back to Fusebox 2. We work on new projects in common frameworks like FW/1 or DI/1, but we also support a host of legacy applications done on custom frameworks or with no framework at all.

As stated above, our positions are full-time remote telecommute. On rare occasions they might require some travel. We pay a competitive salary and benefits. CF Webtools maintains sites on virtually all ColdFusion and Database platforms. Our work is challenging, invigorating, sometimes poke-your-eyes-out frustrating, but never boring. Our development group is full of witty, interesting and extremely talented developers. It's a true mentoring community. If that sounds like a place you would like to work (and you meet our high skill-set standards) send your resume to jobs@cfwebtools.com - or contact the Muse directly if you like. Tweet me @cfwebtools or use the "Ask a Muse" link on this blog (I'm easy to find). You can also call 402 408 3733 and ask for Mark or Jason - we'll be thrilled to speak with you about our opportunity. The official job posting may be found on our corporate site at the Job Openings page.

Always Check on the Last Thing You Changed

If you can sing this with a sort of smarmy accent like Eric Idle it makes it really pop to the tune of "Always Look on the Bright Side of Life".

Your server's feeling bad,
It can really Make you mad,
JRUN maxed can make you swear and Curse,
When your chewing CFGristle,
Don't Grumble, Give a Whistle
And this will help things turn out for the best

Always check on the last thing you changed
(whistle cheerfully here)
Always check on the last thing you changed.

If CF's being Rotten,
There's something you've forgotten
And that's to check the freaking SVN,
For anything that's newish
Roll it back, don't be bluish
Just pucker up and whistle, that's the thing


Always check on the last thing you changed
(whistle cheerfully here)
Always check on the last thing you changed.

...I'm not sure what was in that mimosa...

Protecting the CFIDE directory in IIS

Yesterday I had a server with IIS and a few hundred sites on it. Some, though not all, of the sites had an unprotected CFIDE directory mapped. So my task was to protect these directories by denying all IPs from access except a specific IP range. Before I describe the task and my trick let me remind you that this is not time to tout Linux or Apache or bash Microsoft in the comments. The muse welcomes comments but enjoys variety. We all know about Apache and its manifest benefits. We don't need you to remind us in spite of your excellent credentials and biting wit. IIS is fine platform with many strong points too and there are folks who need this information. They should not feel like they are sneaking into the adult section of the video store to get it. Now back to the Muse' usual good humor. Here's the scoop....

Read More

That Pesky CFIDE Directory

If you are CF community connected (and if not why not?) you know about the latest "sub-zero" exploit to ColdFusion that once again targets the Administrator or adminapi directory under the CFIDE directory. It leverages tags that work with files from within these directories to place code on your server which can then be leveraged to do other things. Basically it can function as a hostile takeover of your server. See this entry titled 0-Day Exploit for ColdFusion by the awesome folks at Edge web hosting for more information. It will point you to the Adobe Docs. The exploit targets CF 9 and 8 if I'm reading the source correctly.

The lockdown guide will give you a few dozen steps some of which will have you pulling out your hair unless you have carefully built your server. But the main "fix" for this exploit is fairly simple. Do not allow arbitrary access to the CFIDE/Administrator and CFIDE/adminapi folders from the web. This seems to be pretty head scratchingly obvious but you'd be surprised how many folks say "But don't you need a password to get into the administrator?". Yes, and you need a key to get into your house too, but an "exploit" is rather like a brick through the window. To really secure your house you need a security system, good locks, good lighting, and a Rottweiler the size of a pony.

Why is it there in the first place?

This is a question I get sometimes. "I don't remember adding that virtual directory. How did it get there?" No you did not fugue off while adding web sites - unless you see one for a Ukrainian tether ball team or something - then probably yes you did fugue off. The real story is that when you install ColdFusion using selecting the "configure all websites" option during the install the CFIDE is mapped on all the sites on your web server as a physical (for the default site) or virtual (for everything else) directory. That's how it seems to "show up" everywhere. In addition the "connector" scripts - the ones you run to "remove all" and "add all" will add it as well. If you are like me you configure each site separately outside of the CF ecosystem. Then you join it to the ColdFusion engine using wsconfig. My servers use the multi-server config and I use the built in web-server (at ports 830X) to admin them from inside the network. When a new site is needed I add it in IIS or apache, then I use wsconfig to connect it to the ColdFusion instance I want. Yes it's extra steps and yes it requires more knowledge, but it's the way I like it. And I'm worth it. Doing it this way does not add the CFIDE directory by default - which is why if I need the scripts directory I use an alias or virtual and alter the setting within the admin.

But what I notice from time to time is that there actually is a CFIDE directory that shows up on some of my sites. How can this be? I've been so careful. Here's what happens. A team member - a developer - is assigned to a site for the first time. Perhaps this is the first site they have set up on their local environment, or perhaps they are sys admin challenged and don't know how to create an alias or virtual directory. For whatever reason the CFIDE physical directory is installed and is living in the root directory of the site. Then at some point the developer remembers (through the prodding of his project manager) that he needs to do regular updates of our subversion repository as a part of his task list. Suddenly (with apologies to Emeril if he's still alive and has not exploded) BAM! the CFIDE directory itself is now part of the source code. Our Jenkins CI server ignores this directory and does not deploy it to either staging or production but usually the initial site setup is not done by Jenkins. So one thing leads to another and the directory is deployed to staging (small yikes) or production (big yikes and a shudder).

Of course this is bad in more than one way. For one thing this directory has the vulnerabilities in question in the form of CF Scripts. For another it is likely not being used to admin the server - which means that updates in the form of hot fixes and security patches will never make it into this code. It might also end up being the wrong version of admin as the site code is transitioned from version to version. I'm not sure if that last is bad or good - but it is another thing to worry about.

In conclusion get out there and secure those directories (and other things). Let's make sure we are on top of this before it get's out of hand. :)

Setting Timeout Successfully on a Web Service Call

One of the annoying things about ColdFusion (yes even the Muse gets annoyed) is the sort of haphazard way it deals with timeouts. If the process you are timing out involves a call to an external service it's really a crap shoot whether or not it will work. Once CF hands off to the external service and starts its vigil waiting for the callback, the timeout value is largely ignored. Don't believe me? Create a long query to a DB Server and then pull the network cable while the query is running. The thread will usually continue to hang even if you have added a timeout value.

Recently Super Guru Jared Riley (Computer Services Inc. (CSI)) was lamenting this very problem with regard to a web service he was using. Because the web service would sometimes hang at the other end due to reliability issues his server was accumulating dormant ColdFusion threads which eventually would fill up the simultaneous request pool and begin to queue all other requests - effectively locking up the server.

It turns out a savvy developer named Jeff Nelson (also of CSI) came up with a solution for this particular issue. Before I share I must warn my readers that this is an undocumented solution that sets an underlying AXIS property. That means that subsequent changes to some future version of the underlying Axis libraries could cause this to error out at some point. The Muse has been known to use undocumented features successfully from time to time - but it pays to be vigilant when upgrading or patching. Also keep in mind this is only for web services. It will do nothing for Queries or cfmail etc. With that in mind here is the "fix".

Setting the timeout axis property

Now some of you might immediately say "hmmmm.... that's the connection timeout, but it doesn't really cover long running requests that occur AFTER the connection is made does it?" Jared has actually done a good bit of testing and claims that this property will timeout a request for either a connection reason or a time of process reason.

So if you are trying to solve this particular problem this might be an appropriate course of action. Now if we could just find similar settings for various DB Drivers my life would be complete.

Follow Up

For those of you who want to remind me that there already is a timeout property to cfinvoke that can be used here I would respond that that setting works correctly for creating the stub classes. In other words if ColdFusion can't compile the WSDL with the time alloted it will timeout. But it doesn't work for actual calls to the methods instantiated.

In the Hunt for ColdFusion Programmers (Again!)

It's that time again. CF Webtools is looking for a talented, advanced ColdFusion programmer. We value a developers who:

• Take ownership of a problem and find a solution.
• Participate in the community through lists, blogging, user groups etc.
• Have a high skill set and a professional learning ethic.
• Know how to communicate technology concepts across disciplines.
• Respects and honors our customers.
• Have a great sense of humor.
• Love being a part of a "family" of developers who work together without a lot of drama.

For more info on what it takes to be a CFWT consultant check out my post on You Might be a Muse All-Star.

Frequently Asked Questions

• Do you allow telecommuting? Yes all our development positions are full-time remote positions.
• What sort of dev environment can I expect? We are en eclipse shop and rely on SVN, Jenkins, and an agile like approach to development. Having said that, as an outsource development company we frequently integrate with external teams. That means you can't always predict everything about the approach for the project you are working on.
• What Industries are you working in? We have sites we develop and maintain in the Financial sector (stocks, options, commodities, retirement planning and management etc.), Insurance, Medical, Pharmaceutical, retail sales, real estate, etc. We have a very broad client list.
• Will I get to meet the Muse? Yes of course... you'll be sick of me inside of two weeks.
• Do you use frameworks? Yes - all of them all the way back to Fusebox 2. We work on new projects in common frameworks like FW/1 or DI/1, but we also support a host of legacy applications done on custom frameworks or with no framework at all.

As stated above, our positions are full-time remote telecommute. On rare occasions they might require some travel. We pay a competitive salary and benefits. CF Webtools maintains sites on virtually all ColdFusion and Database platforms. Our work is challenging, invigorating, sometimes poke-your-eyes-out frustrating, but never boring. Our development group is full of witty, interesting and extremely talented developers. It's a true mentoring community. If that sounds like a place you would like to work (and you meet our high skill-set standards) send your resume to jobs@cfwebtools.com - or contact the Muse directly if you like. Tweet me @cfwebtools or use the "Ask a Muse" link on this blog (I'm easy to find). You can also call 402 408 3733 and ask for Mark or Jason - we'll be thrilled to speak with you about our opportunity. The official job posting may be found on our corporate site at the Job Openings page.

CF 10 Does Not Honor "Maxrows" on Sybase Stored Procedures

In working with CF 10 on a site that uses Sybase as a backend database server one of our tasks was to convert various "inline" queries over to stored procedures. In some cases these queries used the "maxrow" attribute to limit the number of rows returned to the driver. Personally I usually revert to LIMIT or TOP (or whatever the DB Server syntax provides) for that purpose. With maxrows the DB server works just as hard (my best guess) and the driver simply counts the number of rows sent to the buffer and limits it there. In other words, I have always suspected that maxrows limits the number of rows sent from the DB Server and not the number of rows actually produced by the query. Still there are situations where it hardly matters in either case - and maxrows has a purpose there I guess.

So when it came time to convert our queries over to stored procedures - and with a requirement to change as little as possible on the DB Server - we dutifully added the maxrow attribute to our cfprocresult tag like so:

But to our suprise this had no effect. Sybase (or perhaps the Sybase db driver) simply failed ot honor the maxrows attribute. This might be one of those cases where only some drivers or DB servers are capable of implementing the attribute for a stored proc. For example the attribute dbvarname used on the cfprocparam tag is ignored by several DB servers (MSSQL among them). You must place your params in the correct order instead. Still, I wish an appropriate error message would be thrown rather than simply allowing the stored proc to execute and ignoring the attribute like a quirky basement dwelling uncle. Anyway I thought it was worth blogging this nuance of the Sybase driver for the 6 ColdFusion servers out there still connected to Sybase. :)

Debugging and a Return to Dodge City

One of the things the Muse likes best about ColdFusion is the excellent debug information provided during development. Of course you should never ever leave debugging enabled on a production server. Not only are you generating a great deal of additional data with each request (adding overhead), you are potentially exposing a mother lode of technical information that a nefarious hacker would salivate to see. But during development, the debug information is where you ought to live. Indeed, if you are not constantly checking the debug information start doing it now - make a habit of it! You will learn things about performance, iterations, database interactions, cookies, paths, and all sorts of goodies that will make you a better programmer.

I've had my head buried in the debug information since I started with ColdFusion. Back then (in the Wild West days of CF 4.01) we never heard of newfangled ideas like "cfqueryparam". We just stuffed our variables into queries willy nilly and trusted the good Lord to protect us. It feels like I have spent the last 7 or 8 years cleaning up after code written like that. But writing queries in the raw (unprotected I mean... I don't generally code naked, although I did experiment in college) had one main advantage. As you probably know a lot of debugging goes back to the database. The debug output pre-cfqueryparam was "well formed" query code that could be copied and pasted directly into a query tool like MSSQL studio or Navicat. This made debugging pretty easy. You could swipe a problem query out of the debug, run it and tweak it unit it gave you what you needed, then past it back into CF. But that changed when we all started using CFQUERYPARAM.

Read More