CodFusion

I’m not a big fan of client variables and really never like how they were put together to begin with, but what is worse is that I see people turning on client storage and unknowingly running into problems. In the next release of ColdFusion, it would be nice to see some changes to client variables.
 
So if you don’t know about client variables, the reason they were created was to save information for a client across multiple browser sessions. As a distinction, Session scope variables are for a single browser session to an application. So client variables for example might be used for a site that may have the ability for users to customize their homepage, etc. Those settings can be saved in a client variable for future visits to the site. At first look this does not sound like a bad idea, but people routinely abuse this variable scope in a variety of ways. By design, complex objects could not be saved in the client scope, just name and value pairs. But early on, people learn to simply convert objects with cfwddx and dump the xml into the client scope, or they would turn client management on via the application setup and not even use the scope. The other common area of abuse is simply saving critical information in the client scope which it was never design for.

On the server side, client variables are active by default. You can’t turn them off. That would be nice to change. There are also three options on the location to save client scope variables. The default option for a windows environment is the registry!

Why this was even an option has always been a mystery to me. Here is the reason why.

If someone doesn’t change the server defaults and also turns client management on for their application even if they don’t need them. They will start dumping CFID and CFToken information straight into the server’s registry which is located at HKEY_LOCAL\Software\Macromedia\ColdFusion\CurrentVersion\Clients
 

By saving in the registry, these record changes can become very expensive very fast. The majority of the system’s registry is saved in a special file call the server’s pagefile usually located at C:\pagefile.sys

Now when a server starts running slow or takes a long time to start up, many people look at processor(s) or memory usage to determine why, but the one of the biggest causes for slow server performance is disk I/O reads and writes. One of the main causes for this is a system pagefile running larger than it should. By dumping client variables into the registry and thereby into a large single pagefile, I hope you can see how easy it is to destroy a server’s performance with this. If the server gets a large number of users, this setup can become a mess in a short period of time leaving many people to wonder if ColdFusion can scale up to the load. So, it begs the question why this was ever determined to be an option much less a default setting. Frankly, the registry option should be taken out for good on the next release. There is no reason I can think of that you would ever want this on.

A couple of best practices notes…
Other people turn client management on via the application.cfm (or cfc) and never even use the client scope? They may copy/paste their code or have a handy snippet, but take two seconds to check and see what you are turning on and if you even need it. Others may like to WDDX information into the client scope. Once again, check your storage options. This is an interesting hack, but you could be barking up the wrong tree with this one. 

Now the other options for storing client variables are cookie or datasource. Cookies have their issues and you should take great care to determine what to save in a cookie. There are plenty of cross-site scripts (XSS) attacks that focus in on cookies. The better option is to use a datasource, but here again there are some changes that should be made in the next release of ColdFusion. You could, for instance, choose a MS-Access datasource to save your client variables. Sorry, but that’s not much better than the registry option. You will still have bad I/O performance using Access or any other file based datasource. The options really should only show SQL Server or Oracle options and maybe MySQL only. This would prevent people from choosing the wrong datasource. As a further note, it is important to have the client storage database to be a separate datasource from your application and any other critical databases. It is simply too easy to access a client storage datasource and always make sure not to save any critical information into the client scope such as credit card information, etc. The design of client storage is simply not compliant with PCI-DSS standards.