Legacy Code Part 8: Protect Your App Now

There's been a lot of publicity, recently, about the loss of sensitive PII (Personally Identifiable Information) on the web, and legacy ColdFusion applications have been hit especially hard. Hopefully, by now, you've upgraded to the latest version of the server, but that isn't enough. You've got to start actively protecting your system. One area of this is code, specifically in protecting your database from form and url hacking. (Remember Little Bobby Tables?)

Just like everything else we've discussed about upgrading your Legacy Code, the rest of your progress is handled mostly in baby steps. With one, notable exception. You have to lock things down, and prevent these security breaches.

Some time ago, ColdFusion introduced the <cfqueryparam> tag, as a way of creating bind variables in your queries. Aside from providing sql type checking to each param, it creates some inherent security by converting these arguments in to bind variables, in the SQL request. This is a double bonus, in converting Legacy Code, as you get both the security, and performance enhancements, by using bind variables. (Use <cfprocparam> with the <cfstoredproc> tag, for making stored procedure calls.)

This can be one of the single most important things that you do, in securing your application from outside attack. Make a project today of converting every single query call, in your Legacy Code, to utilizing <cfqueryparam>. It might take you days, or even weeks, but it will be your very first line of defense. Don't just do those that are form inserts, or those that reference URL. Do all of them.

Now, there are other things that you can do to protect your app as well. Review the ColdFusion Lockdown Guide, and implement those changes relevant to your system. Run the FuseGuard Application Firewall, as an added layer of security. And, run your site through HackMyCF. The free report can give you some valuable insight on things you can do right now, and a paid subscription can give you even more information.

Don't forget: fix every query. Calling a stored proc from a <cfquery> tag? Convert it to <cfstoredproc>. Leave no stone unturned. And get in the habit of writing them this way going forward. Data breaches are bad for business, so don't become the next news article.

This article is the eighth in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code Part 7: How To Map Your App

So, in our last post we talked about Mapping Your App being your next step, but then a question came to me, "How?"

Well, that's a very valid question. When I took on this exercise, several years ago, with one very large (6000+ template) application, I began by making a basic flow diagram of the existing Application.cfm and OnRequestEnd.cfm. What this ultimately did was A) show me all of the small bits of process flow occurring in these templates, and B) gave me a true understanding of exactly what was happening when. This all allowed me to evaluate each of these small bits of functionality, and determine how they each translated into the new ColdFusion application framework, as it is laid out by Application.cfc.

You can typically break your application down into a few sets of events: Application Start and End, Session Start and End, and Request Start and End. On top of this you have a few edge case events you can cover, like if a request is made of a template that doesn't exist (onMissingTemplate), or it an error is thrown but not caught otherwise (onError).

OK, so saying all of that kinda makes sense. But, what does it mean from an application standpoint? Well, then you have to evaluate the variables you're creating and make sure that you're placing them in the proper persistent scope. You have a utility object that you use everywhere in your application? Then you put it into the Application scope during onApplicationStart. Have a single user object that you use to model each user during their visit? Then you put it into the Session scope during onSessionStart. Want to track each page request by logging specifics to your db? Set some variables at the beginning (onRequestStart), or during your request, then execute your sql inserts when the request is done (onRequestEnd).

You'll start with your initial flow diagrams, and then create some new ones with headings to match the new application framework of Application.cfc. Create a diagram titled "onApplicationStart", and bring in the corresponding flow bits from your other diagram. Move flows around until they're in the order necessary, and in their proper place in event execution flow. Once you moved all of the small sub-flows from the old to one of the new, then you have a roadmap for writing your new Application.cfc.

Need cheap software for making basic flow diagrams? I use the draw.io app from the Google Chrome Web Store.

This article is the sixth in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code Part 6: Map Your App

You've picked up some new hardware, setup a new local dev environment, and started learning the ins and outs of the modern web age. Your Legacy Code is getting more out of touch every day that goes by. Now what?

Let's get started. The first thing you need to do? Map your App. One of the best things to happen to ColdFusion (many, many moons ago) was the introduction of Applications.cfc. Application.cfc replaces Application.cfm and OnRequestEnd.cfm, allowing you a much finer level of control of your application flow. Here's where a solid understanding of how your application works is most important, as you now have the ability to truly target the creation (and destruction) of variables in different persistent scopes.

Remember when I said it was time to learn the latest ColdFusion? Well, this isn't really "new", but it might be new to you, or to this app. A solid understanding of what happens at each stage of process is important, as well as truly understanding proper scoping. I've already blogged about the different stages of application flow in my MSOC series, and you can download my scripted Application.cfc as a template.

Understanding how and when certain variables are added to your application will help you to identify where things might be sloppy or slow. By making your own diagram, you can write out how your app begins, then a session, then an actual request, and then those ends again. You begin to ask yourself "Does this really belong in the Session scope? Or would it be better served in the Application scope?" If your app is on it's own on a system, you may even decide that there are things you could place in the Server scope, and begin to explore using a Server.cfc for onServerStart().

Diagramming your application flow can be very enlightening, and liberating. You really begin to see where some of your app's inefficiencies lie, and how you can regain control. With such fine grained control, it's much easier to write in "reinit" functionality for "resetting" your application. You find that audit logging is much simpler (or just possible) when attaching to every request at onRequestEnd(). You begin to realize that you're hanging on to some data for much longer than you need to, or that you're requesting data entirely too frequently when you really only need it occasionally.

After you've completely diagrammed your application flow, you might begin writing your Application.cfc. Keep in mind that some of your findings may take hours, days, or even months to correct. Yes, that variable really needs to be in the Application scope, but that also means you have to change every reference to that variable across your entire application. Now might not be the time to do that yet. Chances are you will begin with writing your Application.cfc as a direct replacement for your Application.cfm and OnRequestEnd.cfm, and then gradually, over time, correct your past errors. You've got it all diagrammed out now, and having it in writing will assist you in your future patchwork.

What you're doing here is beginning to make a plan. Over time you are going to systematically refactor small pieces of code across an entire application. Migration to Application.cfc is the first of many steps, and probably one of the largest, overall. It's also one of your most important steps, as it really gives you a blueprint for the future.

This article is the sixth in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code Part 5: Crossroads

So, you're committed to bringing your legacy ColdFusion app into this century. You've been following along with these posts, and maybe even started to study some of the latest technologies. Now comes the big question. Are you sure?

Hopefully, you know your app. Is it big? Is it small? Are there a large number of sub-applications? I'm not gonna lie to you, there's a lot of work ahead. A lot of it is very tedious and repititive too. Right now, you are at a crossroads. (How fitting that you're here...) You've got a decision to make.

It's time to look at the ROI. How much time, money and effort do you already have in this application? You have to weight the pros and cons of your actions, in relation to the bigger picture. You have a couple of different directions that you can go from here.

You can just rewrite your app from the ground up. If your app isn't that big, this might be a really good opportunity to go ahead and start from scratch. You might decide, at this point, that you want to work on an entirely different tech stack. OK, I can see that there might be real, viable reasons to go that way. That said, I also know the true Rapid Application Development capable with ColdFusion, in the hands of a talented developer, so for me the reasoning to move to something else would have to be overwhelmingly compelling.

You can scrap your app, and replace it with a COTS alternative. This only works if there is a COTS alternative, and even then you have to find a way to handle data migration.

The final option is to refactor. This will typically be slow, requiring you to pick apart your applications, document process and workflow, and truly think about what's going on under the covers. There will be trial and error. Version control branching strategies will become critical. The big advantage here is, you have code, so you have a blueprint for how it was all supposed to work.

So know, going in to this decision, that if you choose this last option you will have a lot of work ahead of you. But, in the end, you should also end up with a well documented application, for which you will know every in-and-out.

So, time to decide. Are you up for the game? Or bowing out? If you're coming back to the table, in my next post we'll really start digging in on "how" to upgrade that legacy app.

This article is the fifth in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code Part 4: You Don't Know...

You're bringing your ColdFusion app into this century, but you've never heard of CFC's? Still using third party tags for image manipulation? Didn't know there was scripting? Before you start touching your code, it's time to do some research...

ColdFusion has grown a lot, in the past decade. CFC's help create reusable code, and allow for Object Oriented like architectures. There's built in image manipulation methods, MS Office, Exchange, and Sharepoint integration, native JSON serialization on remote requests, PDF creation and manipulation, and a whole lot more. On top of that, you can script most anything now as well. Take some time to look through the documentation to see some of the new things available for your application.

Speaking of changes, the <center> and <font> tags were deprecated years ago as well. Today, we use HTML markup for data, and CSS for display declaration. Get up to speed on HTML and CSS and JavaScript. You're a web developer, not a process manager. All of this data is useless if the user can't "use" it. Learning these things now will go a long way as you bring your app up-to-date. I bet your SQL server has some upgrades too (like stored procs in MySQL).

The web changes at the speed of light. It can take a lot to keep up, but it's necessary in an environment that never stops growing.

This article is the fourth in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code Part 3: The Right Tools

You don't use an butter knife when you need a hatchet, nor a machete when you need a scalpel. When you're bringing Legacy Code out of the Dark Ages, you need the right tools. That old copy of ColdFusion Studio was the bomb in it's day, but it's not working so hot on your new Windows 8.1 laptop. On top of that, it's help dictionary is out of date by about 5 server revisions, and it's never even dreamed of HTML 5.

You need some good tools to resuscitate a dying app, and the first one is a good editor. I personally prefer Adobe ColdFusion Builder, but you could use CF Eclipse or Sublime Text 2. I like an IDE, and love Eclipse for it's plugin architecture, which allows me to handle the majority of my workflow directly in one environment. Others prefer just a text editor, and that's fine too, but at least pick something with code complete and up-to-date dictionary add ons.

Do you use Source Control? Now's the time to learn. The ability to branch, merge, and revert are critical for continuing to maintain a working application at this stage. I've used Subversion in the past, but have come to prefer Git. The learning curve is steep, but the benefits and flexibility are well worth the time investment, especially in a team environment.

Using MS SQL? Then you want the Redgate SQL Toolbelt. This one isn't cheap, but it's well worth the purchase. You can do comparisons of database schemas, source control sql, backup and restore at an object level, document your db, and the compression technology here can save you a bundle in storage costs. And all of that is just scratching the surface.

And when it's really time to dig in, you're going to want FusionReactor. For me, this tool paid for itself in the first five minutes. You can watch every single request that's hitting your app. Track your slowest requests, queries, and more. Get live data on memory utilization. You can setup notifications for different events, and even setup auto recovery scenarios. This is the must have tool when you're modernizing your application.

Finally, if your getting hit with security breaches right now, it'll probably take some time to pay off some of that code debt and get back on track. FuseGuard, from Foundeo, is an easy way to add some badly needed security when you have none. It won't do your work for you, but it can save you a lot of grief while you get it together.

This article is the third in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code Part 2: Getting Started

Your ColdFusion site is crawling. Pages take seconds to render. The DOS attacks from China are taking you down daily. Your boss is crawling up your backside, because clients are running away. And... you're still running ColdFusion 5 and MySQL 3.

Why are you complaining again? Wake Up!

Your problem isn't your platform. It's...your platform. Why would you think that you have to upgrade your desktop software, but not your web platform? Every new iteration of an Operating System becomes (hopefully) a little more performant and a little more secure and (generally) has a few more bells and whistles. So why are you still running IIS on Windows NT?

You want things to get better? Want the boss to stop breathing down your neck? Step 1: Get Current. If you aren't up-to-date, your app will show it's age. We can get wrinkled and put on weight with age, why wouldn't your site?

Give your site a Lifestyle Lift. Get a modern OS, a modern web server, a modern database server, and a modern app server. (And, if you're that far out of date, you probably need some modern equipment too.) No budget for all of this? Consider a hosted VM instance(s), where the host handles the software licensing.

The language has changed/improved, a lot, in the past decade+. So has the server. You can't take advantage of any of these enhancements if your infrastructure is archaic.

Now, all of this being said, you'll want to test your code on a local architecture of the same make up. Chances are that there are minor code changes that you will have to make just to get up and running on "New Stuff". Set yourself up on a local VM, with all the same upgrades (OS, web server, db, etc) and thoroughly test your application. Having trouble? It's worth the time to test and figure it out (or hire a good consultant).

This article is the second in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code: Coming In To This Century

For more than a decade now, I've made a living upgrading legacy applications. Many times, these are applications originally built on ColdFusion 4 (or even earlier) and never touched again. Some company invested thousands, or even tens of thousands of dollars having an application written, adding to it over and over with time, but never refactoring it for a new age.

This is probably the number one issue with how ColdFusion gets viewed, as a language and a platform, from outside the ColdFusion community. There are these huge applications, written on a platform that has grown and moved on, and that old code just doesn't perform the way they want it to anymore. What was written was probably great, at the time, but now there's millions of database transactions, thousands of concurrent users, and changes to processes in general. That old app just isn't cutting it anymore.

The question that comes up for a company, at this point, is do they rewrite the app? Do they upgrade the app? Or do they replace the app all together? Each of these questions have answers with their own pitfalls, but today many companies are looking at this issue and saying that their problem is ColdFusion, instead of seeing it as their answer.

Here's the bottom line: ColdFusion isn't always the answer to every problem. No more so than .NET is, or PHP, or Ruby, or any other particular language. That said, ColdFusion does have a very large advantage, in that it truly is a Rapid Application Development platform. If you know the language, if you know the server, and if you have a solid plan, it is possible to rapidly change an an application, or write a new one.

With this post, I'm going to start a new series of posts about some of the things that I've found, over the past decade, that can be used to bring a legacy application into a new age. There are a number of things that a company can do to bring new life back to that old and frail beast that used to be their pride and joy. More over, some of the things I'll relate can save a company from unnecessarily spending thousands of dollars in redevelopment when they didn't need to do so.

Previous Entries