ColdFusion Security Patches ColdFusion 11 Update 13 and ColdFusion 2016 Update 5
Adobe just released security updates for ColdFusion 11 and ColdFusion 2016. This is a critical security update and you should be updating your ColdFusion servers. The information below is from the CF Webtools operations group. If you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at cfwebtools.com. Meanwhile, this info below will help IT staff and DIY types get started.
With ColdFusion 11 Update 13 and ColdFusion 2016 Update 5 there are additional manual updates that are required to complete the security patch. The additional requirements are the same for both ColdFusion 11 and ColdFusion 2016 and the remaining information pertains to both versions. Both updates require that ColdFusion be running on Java version 1.8.0_121 or higher. For reference, ColdFusion 11 comes with Java version 1.8.0_25 and ColdFusion 2016 comes with Java version 1.8.0_72. The Java that needs to be installed is different from the "Windows User" Java client that may already be installed. The installer is available from Oracle. Once the new Java version installed, the jvm.config file for each ColdFusion instance needs to be updated to point to the new Java version installation path. If you're running the Enterprise version of ColdFusion, there's a likely chance there is more than one ColdFusion instance running.
Part of the instructions from Adobe says that if your ColdFusion server is installed as J2EE server then there is an addiction manual configuration that you ned to do. However, every installation of ColdFusion since the release of ColdFusion 10 is a J2EE or JEE installation. What Adobe really meant was that if you are using a third party JEE server and not the built-in Tomcat JEE server. 
If your ColdFusion server is running on a third party JEE server such as WebLogic, Wildly, custom Apache Tomcat, etc (Not the built in Tomcat that comes with ColdFusion), then the following step needs to be completed.
Set the following JVM flag, "-Djdk.serialFilter=!org.mozilla.** ", in the respective startup file depending on the type of Application Server being used.
For example,
- On Apache Tomcat Application Server, edit JAVA_OPTS in the 'Catalina.bat/sh' file
- On WebLogic Application Server, edit JAVA_OPTIONS in the 'startWeblogic.cmd' file
- On a WildFly/EAP Application Server, edit JAVA_OPTS in the 'standalone.conf' file
This is one more friendly reminder to make sure your ColdFusion servers are patched! Either patch them yourself, have your hosting provider patch them or if they are not familiar or knowledgeable with ColdFusion contact us at CF Webtools to patch your servers.
As always, if you need help migrating to the next version, scanning your ColdFusion server for security vectors or installing this patch and new Java version, contact your project or account manager directly, or send an email to support@cfwebtools.com. You can also simply respond to this email (or call 403-408-3733).
*Note: ColdFusion11 when it was first released came with a version of Java 1.7.0_nn. Adobe later re-released ColdFusion 11 with Java 1.8.0_25. If you have ColdFusion 11 still running on Java 1.7 I highly recommend that Java be upgraded to Java 1.8. Oracle is no longer supporting Java 1.7 and 1.7 is long past it's end of life. Even though the Adobe instructions for this current security update states that you can run Java 1.7.0_131, I highly recommend upgrading to Java 1.8.
Mary Jo Sminkey: Robust Error Handling Part 3 - Ajax
Part 3 in the super-guru's Mary Jo Sminkey's series on robust error handling. Enjoy!
So in my last post on error handling, I promised in this next one to cover logging of Ajax requests. As more and more of our site involves Ajax requests, this has become an important part of my error logging and debug work. If you want to know how to do this read on!
Read More"Send us a Developer Oh Lord!" - He cried from his lonely chariot.
p> Yes yes yes! CF Webtools is hiring again. We are looking for 1 to 3 advanced ColdFusion programmers to add to our already large team of CF folks. Here's the stuff everyone wants to know.
- Yes these are remote development positions.
- No we are not hiring outside the U.S. (sorry!)
- Yes the position is W2 with benefits after a short (30 day) trial period.
- Yes benefits include health care.
- No our health care is not as good as congress' health care - but it's pretty good for a small company.
- Yes there are other benefits - 401k, dental, PTOs, disability, life insurance, and hearing from me almost every day.
- No our developers don't walk on water every day - we save that for the second Tuesday of months ending in "Y".
- Yes we work on interesting projects and applications accross the board in Insurance, government, health care, finance etc.
We are a company out to build a positive culture and work environment where you can shine and feel good about what you do. We are looking for developers that match our culture of Can-do, Caring, Communication and Competency. Here are some examples of what we expect.
- You should be able to setup multiple local environments, or at least not be scratching your head at that phrase. Mac and windows are required. Advanced developers do advanced things like (for example) set up an Apache or IIS web site and connect ColdFusion to it. We see this as indicative of your problem solving ability as well.
- You should be able to work with SVN or GIT (and no we don't want to see your white paper on why GIT is superior).
- Maintain positive attitude - We are not looking to hear about your pet technology peeves, your problems with Adobe or why the command line is always superior to a gui. If you are not interested in being a net blessing to a larger group (or if a lack of snark makes you queasy) we are probably not a place for you.
- Maintain and enhance your skills set - you will be given the opportunity to work on lots of code, different versions, platforms, integrations, libraries and SDLC organization and procedure. Everyone of these is a growth opportunity. If that has you licking your chops climb aboard.
- Balance - We like devs who have a full life. If you enjoy fencing, equestrian sports, skydiving, guitar playing, dog training, macrame, Golf, racquetball, Mandarin, Politics (careful!), family outings, child rearing, school plays, choirs, baking (all activities enjoyed by folks on our team) then we think those things make you a better developer! We aren't looking for 80 hour a week developers slavishly devoted to coding. We are looking for eclectic, interesting people who enjoy coding and want to do it for a living.
Up to $1000 Referral Fee!!
CF Webtools has revamped its awesome referral program to make it awesomer - or even more awesome. As you may know we have been offering generous referral bonuses to developers for years. If you bring us business we try and reward you. In 2016 CF Webtools paid out nearly $100,000 in referral bonuses! But our old program was hard to understand so our marketing guy - Curt - has twisted my arm to make better.
Here's the Deal
If you bring us business you get $500.00. Any business. A mom and pop store, someone selling pet insurance, an app for measuring dog poo by volume and color - we don't care. If it's business and we make a sale, you get $500. But wait there's more. If said business turns into at least 150 hours you get an additional $500! So, you can make $1000 just by name dropping.
The Part Curt Doesn't Like
Now I will have to avoid Curt for a few days after I say this, but if you bring us a whale - a customer with regular work involving at least half a developer (hopefully the top half) I will be even generouser - or even more generous. Call me and we'll make a deal. I promise we'll make it worth your while.
CF Webtools Pledge
So, your grandma is selling needle point online and you want to refer her to us but you are afraid. Maybe you fear we will treat her poorly, or that we won't take "needlinggrandma.com" seriously. Be reassured by the following Muse Pledge to you:
We will Reward You.
We will Make you Proud.
We will not Embarrass you.
We want to make you happy you turned over work to us. We will make every effort to insure it is a good experience.
What sort of thing qualifies?
CF Webtools has a large and diverse staff. Don't assume we won't be interested just because we shout "ColdFusion" all the time. We have a dedicated operations group for managing large technology stacks. We do IOS and Droid development. We manage complex databases and are familiar with many different environments. Give us a call and find out.
It's complicated
Ok, so you have a problem client or former employer where you had a bad experience. We get that. From month to month we are often embroiled in handling a "hand off" from a developer or company where things went south. We specialize in working hard to smooth things out for the customer and we do it without throwing the former developer under the bus. We will concentrate on the work and do our best to make you look good. If you don't want us to mention your name we won't. If it will help and you say it's ok we will. You will find us easy, dare I say charming to work with.
How do I make it happen?
- Call Curt Lovegren at (402) 408-3733 ext 104 or...
- Email your lead with as much information as you wish to cfleads@cfwebtools.com.
We'll look to glean any information that can help us be of benefit to the prospective customer. Just reach out and let our staff do the rest. Easy, right?
Building a Robust Error Handler Part 2
The Muse is fortunate to have a number of very talented and smart developers work for him. Mary Jo Sminkey has been with CF Webtools for several years now and we simply love having her around. She's a fantastic developer and a fantastic resource. You might catch her at cf.objective() where she will be speaking next week.
Meanwhile, you might remember part 1 of this series – Building a Robust Error Handler. Below is part 2 in that 3 part series. Enjoy!
Well it's taken a couple years to get around to it, but at long last here is part 2 of my error handling post! Of course, in that time I've continued to work on improvements to my error handler, so many changes that I'm going to need to break THIS post up into multiple parts as well. I'll try not to take too long to get the final part out to you!
So in part one we looked at things like using the error handler for both global errors as well as in cfcatch blocks, dumping all the available scopes while scrubbing them for any sensitive data, keeping track of already reported errors to prevent receiving tons of duplicate emails for the same error, etc.
In this post (part 2) we will expand the functionality of the error handler and talk about strategies for use throughout the application. Let's start with how to handle errors "in depth".
Read MoreCustomers and how they Contribute to Estimating Angst
This is the moment the developers have been waiting for. After having thrown both the developer and his application under the bus, we are going to make room under there for the customer. Now if you are customer reading this, take heart. While I'm going to say some things that will hurt, in the end I'm going to rub salve on the wound and we will all sing Kumbaya together. Here we go.
The Muse finally has a number - a project that we've estimated at 350 hours. Of course, this estimate is not correct. Why? Because no estimate is ever correct. Please refer back to the first post in this series. The majority of estimates are wild guesses. We've done our best to find out all we can about the system, requirements, priorities and every little nitpicky detail we can imagine. Our estimate is based on that discovery. If all of our dozens of assumptions are correct then our estimate is rock solid. But of course, there are still things we don't know and many of our assumptions are simply off. Much of what we need to know we simply can't know until we dig in and start doing the work. For that reason we will give Bob a range of hours - say 275 to 375 hours - and dozens of caveats that he will epically fail to hear and absorb. What he will hear is the number 275 and that will be the basis of his expectations.
Let's check in with the Muse and Bob as they finalize the project.
- Muse: Well Bob, as you can see by the painstakingly detailed 13 page document in front of you, we estimate 275 to 375 hours. Have you read the document?
- Bob: I read... I got to page 2... uh... I did see the estimate at the end. So, 275 hours?
- Muse: [caveat 1] 275 hours to 375 hours. You can expect it to be somewhere in the middle.
- Bob: 275 eh? Wow that's a lot. But I get everything I asked for?
- Muse:[caveat 2] To be clear you get everything we have carefully outlined and detailed in the proposal. If it's not in the proposal it would be "out of scope" - not included in this estimate.
- Bob: Well, I can probably swing 275 as long as I can have it in 6 weeks.
- Muse: [caveat 3] Well the timeline depends on resources and other factors. This is probably a one-woman job. It will take her around 4-5 weeks to do the core programming, then QA, revisions etc. You are probably looking at 8 to 10 weeks. [Caveat 1 again] It's 275 to 375 hours not including out of scope items that tend to arise.
- Bob: Hmmm.... ok, I think we can do it. But just one thing. Did we discuss adding reporting to this application?
- Muse: ...
- Bob: Muse... you there? Did we lose our connection?
- Muse: I'm here Bob... I was just asking my assistant to quickly remove sharp objects from my immediate vicinity. Now about your reporting...
Most clients are not quite as bad as Bob. Still, every contractor or development shop owner has a story remarkably similar to the one above. I know most Muse readers are developers. I can see you now in my mind's eye with righteous indignation and clenched fist saying, "You tell them muse, clients are the worst!" But actually, this is not their fault. Your customer has his or her own domain of knowledge. I have a customer who is a commodity trader. I expect him to know the difference between a bull call and a butterfly spread, but I do not expect him to know the difference between MySQL and MS SQL, how the cloud works, or why it takes 10 hours to program something. The basic issue is threefold:
- Communication
- Expectations
- Cart and Horse problems
Developers, Can't Live With 'em, Can't Deprecate 'em
When last we checked in with Bob and the Muse (part 1 - applications) they were trying to come to grips with Bob's complex... I mean his application's complexity. We are now at the stage called "developer involvement" where he and the Muse are speaking with Sugar Sweet - the Muse's crack developer (and the name of a girl I dated in college). Let's go live to the conference call (be careful not to spook them).
- Muse: Ok, we've outlined changes to the onboarding and broken it out into 3 programming tasks. Sugar will get us an estimate but it seems straightforward.
- Sugar: Muse, a moment.
- Muse: Sure what is it sweetie? (Don't judge me - it's her nickname so it's not harassment)
- Sugar: I've taken a look at this application and the entire thing will need to be rewritten.
- Bob: Wait what? That sounds expensive.
- Sugar: I'm afraid we have no choice Bob. It's written in tags and the variable naming is all wrong. Plus the previous developers used... sorry, this is hard, I'm getting a little choked up... cfqueries instead of stored procedures. [small sob]
- Muse: I'm going to step in here while Sugar get's a drink of water. We will work to retain as much of the legacy code as we can and focus only on security issues Bob. In other words we Won't refactor your code unless it's necessary to protect your investment. How does that sound.
- Sugar: [sounding a little hurt] But the queries... and our best practice guide!
- Muse: I think we can work with what we have here...
- Sugar: This is so hard. I feel beet down. I'm not sure I cane work here anymore.
Developers come in all stripes and their views will greatly impact your estimate. Some of them have a religious devotion to certain technologies, libraries and approaches to development. To be a developer (at least on my staff) requires high aptitude, intelligence, breadth of knowledge and confidence. Those traits generate towering personalities like the Muse (whose lack of modesty is his only real flaw), and of course egos. They have opinions and they are usually not afraid to use them. Their defensive ferocity increases exponentially the closer you get to their favorite technology. If you don't believe me try yelling "Windows rules" at an IOS conference (and hope it's not an open carry state). For this reason, it's always a good idea to have non-developers involved in your estimates. Around here we call them project managers. They use their knowledge of the developer and the customer to "find the sweet spot" that meets the needs of the application and its stakeholders.
Of course, not every estimate needs the once over by a project manager, but larger projects or enhancements should always be a collaboration. Developers need to be able to justify the estimates they provide to someone who knows them well enough to understand how they might get tripped up. Here are a few "types" of developer estimators.
The Refactorer
Sugar is in this camp. She will like over-estimate every task on older code because she sees any legacy code as debt that needs to be paid. To her this isn't optional, it's essential. In the real world it's definitely optional. Is script better than tags - in most cases yes (don't email me). Is using jQuery better than custom JS libraries? I believe it is. Are stored procs better than queries? Usually they are (though I've seen some god-awful stored procs). Best practices, frameworks, indentation, file naming conventions - these are all important parts of competent development. But when approaching legacy code there is a lot to consider. For example, has the customer managed to get a return on his initial investment? If he has, he may be ready for a rewrite. If not, we may need to work with what is there and not break the bank rewriting huge swaths of code. The business decisions rule the day. It's important for developers to understand the economics in play.
The Blithe Underestimator
Estimating is about imagining what could happen. What if the user doesn't check the box - what happens then? What happens when a user doesn't follow your pattern and puts in letters where numbers are indicated? Most developers react to these conditions with frustration. Who would do that? Why would a user use the application in that way when it's clearly designed to be used this way. A good estimator considers all these what-ifs. Estimating is also about accounting for what you still don't know. It's about challenging your assumptions. The underestimator concentrates on what he sees in front of him. His estimate comes with the caveat "if all my broad assumptions are correct". A good project manager will know the developer well enough to A) challenge him on his assumptions and B) add hours to the final estimate to insure it's adequate.
The Over-Complicator (Chicken Little)
Some developers are the opposite of the blithe underestimator. Instead of broad assumptions they build a huge list of unknowns and caveats. How do you know if you are an overcomplicator? Here's a little test for you. Let's say uou pull up Google and the page fails to load. Order the following list by probability.
- Google is down
- The entire internet is down
- It's the zombie apocalypse
- You've typed in "gloogle.com" accidently
- Your wireless connection is bad
- The network is under attack
- Your mom changed the wireless password again (for those you working in your basement)
- The NSA is monitoring your computer
- DNS is not responding
Some time ago I was helping a Muse reader with an error via screen share. On the screen the error debug information had query code and indicated a malformed query. I asked what he had tried. "I tried a new DB driver, checked the network connection and I've been googling how cached execution plans work." I took a closer look at the debug output on the screen, highlighted a portion and said "You are missing a comma after this column." A good manager will know his devs well enough to spot an over estimator and adjust estimates accordingly.
The Technology Hammerer
Finally, there is the developer for whom everything is about tech. The saying goes that when your only tool is a hammer everything looks like a nail. Developers need to be reminded that what they are solving are behavior problems, not (typically) technical problems. When we build a new search engine for a company selling nuts and bolts, the problem we are solving is not faster indexing, better sorting, or more granular pattern matching. nope. It's the basic problem of folks rummaging through bins trying to figure out thread and length. We are trying to make that task easier.
The tech hammerer will turn to the technical aspects of a project over and over because that is her comfort zone. She will suggest products, approaches and solutions that may or may not solve the basic problem underlying the project.
Tech hammerers usually need to learn that it is highly beneficial to gather domain knowledge about your customer. What does the company do? How do they make money? (that's the most important question for a dev company like ours) What sort of problems do they solve with their application? These questions inform our decisions in ways that mere technical questions cannot. Moreover, they tend to make us better partners - better at suggesting changes that save or make money for the customer. "What if we chose to do it this way Bob, would that save your users a step? Do you really need this field, it seems like we have this covered with earlier data. Explain how this will help your user - I want to understand."
Conclusion
The main takeaway here is that developers and their personalities have an impact on your estimates. Estimating is a team effort and requires give and take from several sectors. In our next post we are going to throw customers under the bus - gently of course.
Why is Estimating So Dang Hard
Let's go Live to Bob and the Muse
Consider this typical interaction with a prospective customer:
- Muse: Tell me what you need Bob.
- Bob: I have an application hosted on ColdFusion 9. I want to upgrade to the latest version and move it to the cloud.
- Muse: That's a good choice. The latest version of ColdFusion performs splendidly in the cloud and is much easier to manage. (yes the Muse uses words like "splendidly").
- Bob: Great! How much will it cost me.
- Muse: Well.... [lengthy pause]
- Bob: Did I lose you? Muse... Hello...
- Muse: Oh I'm here. I have some questions. What kind of application is it?
- Bob: It's a customer portal where folks log in and use our whizzbang service.
- Muse: Do you use any third party APIs?
- Bob: Pbbbt... of course not.
- Muse: Excellent - how about jar files. Do you remember using any jar files in your code to access Java stuff?
- Bob: Jar files? What in the ham sandwich is a jar file?
- Muse: It's a way you package Java classes. You might use it to do some complicated Java thing that ColdFusion can't handle on its own.
- Bob: Uh... [Lengthy Pause]
- Muse: Did I lose you? Bob... hello? Maybe we'll put a pin in that one.
- Bob: Sorry my eyes just glazed over there for a second. Anyway, how much did you say?
- Muse: Well I'm not sure I have enough information to uh...
- Bob: Oh! and we also need to upgrade our thingy that posts reviews to Amazon and Yelp. Something about bees... apiary or something.
- Muse: API Library maybe?
- Bob: That's it!
- Muse: [banging head on the desk] ok how about you walk me through the app.
- Bob: Sure ... but... how much will it cost?
Now it's not the Muse's fault that he's having a hard time communicating. After all, if it was easy I'd be flipping burgers and still driving my '72 delta 88 from College. And before you get all up in Bob's grill, it's not his fault either. We IT natives tend to use lingo as if everyone has been exposed to the concept of an "API" or "java integration" or a "mouse".
So I'm going to let you in on a little secret. The bald truth is that development companies usually have no idea what something will cost even after you describe it to them thoroughly. The most accurate estimate for enhancements will always come from the original developer, and even then, they are often guessing wildly.
Chances are if someone is throwing numbers around without asking a lot of questions and without being nervous about "guaranteeing" the cost, you are about to enter a relationship you will regret. Think Vegas chapel and too much bourbon and you'll get the idea. To help further the conversation about estimates I offer this 3-part blog series on "The hard task of estimating". My hope is that in the end, readers who are customers and readers who are developers will both come to understand a little more about this maddeningly ticklish task that we all must do.
Estimating is hard and estimates are often unreliable because of three main areas where issues arise:
- Applications
- Developers
- Stakeholders or Customers
Read More
Sites to Watch
Aggregators
RSS
