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...
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
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.
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. :)
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".
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.
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.
It's that time again. CF Webtools is looking for a talented, advanced ColdFusion programmer. We value a developers who:
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 firstname.lastname@example.org - 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.
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:
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
In my last post on this topic back in September, Phase II - The Clone Wars, I discussed the first phase of our business development. We talked about how I tried to duplicate my own skills and energies by hiring likeminded folks, and how this led to a lack of diversity and innovation. In this post we will pick up on some of the solutions to those issues. Let me say at the outset that some of these issues (founders syndrome for example) are systemic and require constant vigilance and an ongoing effort to resolve. After all, we didn't come up with this list overnight at Denny's and pop in the next morning with neat and tidy solutions to all of them. Some of the items on our list (the need for sales, the value of diversity, the importance of management, team building etc.) required some convincing and cajoling and even some hard knocks to move us in the right direction. But I can say that in spite of "peaks and valleys" (which was incidentally my nickname in high school) we are moving in the right direction. So let's talk about solutions for moving off of the clone model and to something more workable for a larger, team-oriented staff.Read More