|Developers often want to deploy their code without source (sourceless), and while this has long been a problem for ColdFusion developers, BlueDragon has solved this problem since 2003.
Developers familiar with the ColdFusion CFENCODE (or previously named CFCRYPT) utility know that there are ways to revert that back to source code. Many developers have simply given up on the hope of sourceless deployment.
BlueDragon offers sourceless deployment with a feature called Precompiled, Encrypted CFML Templates. Offered in all but the free Server edition, you can create precompiled or encrypted templates from the Admin console or via a command-line utility. (The free Server edition also cannot process precompiled or encrypted templates, but all other BlueDragon editions, including in their trial and developer modes, can run precompiled/encrypted templates.)
The output of the process for each input .cfm (or .cfc) file is a new file with the same extension, but which is not human readable. (See the BlueDragon User Guide for more information.)
Note that you can compile all or just some of your CFML templates.
Additionally, BlueDragon uniquely supports setting an expiration date for your code during the precompilation/encryption process, so your code can be offered as a trial that will expire on the date set. Note that only the code expires, not the BlueDragon engine, so to offer a new set of code without an expiration date (or with a new one), you only need to give the client the new code (there's no need to reinstall BlueDragon).
Finally, note as well that the encrypted templates feature also offers greater security in a couple of different aspects.
If you'd like additional background information on the precompilation or encryption processes, see below.
Background: Page Processing
To understand this unique feature, it's important to understand how BlueDragon processes CFML templates (pages). CFML processing is done by BlueDragon in two steps:
- In step one, BlueDragon "parses" the static information in the CFML page (which tags does it contain, what attributes do the tags have, which portions of the page are plain HTML, etc.) and creates a representation of the page as an ordered collection of Java objects.
- In step two, the objects created in step one are "rendered" to create the HTML response that's sent to the browser. This is the dynamic, "runtime" step where expressions are evaluated, queries are executed, session and client data is managed, etc.
The parsing step only needs to be done once, the first time a page is requested--the object representation of the page is stored in memory in BlueDragon's "file cache" and the CFML source code isn't needed anymore. For subsequent requests for the page, the object representation is retrieved from cache and rendered directly. Of course, if a page is removed (flushed) from the cache, or the CFML source file is modified, the parsing step has to happen all over again.
Here's where the "Precompiled" part comes in. The Java objects that represent the parsed CFML page can be serialized (converted to a byte
stream) and written to a file. Therefore, a precompiled template is one where the CFML source has been parsed by BlueDragon, converted to a collection of Java objects, and then those Java objects are written
(serialized) back to the file in place of the original CFML source. (Note that the process of precompiling destroys the original CFML source, so make a backup first!).
There are two advantages to precompiled templates:
- Because the CFML has already been parsed, BlueDragon can skip that first step and directly render the page. This saves processing time and improves performance, even if the page isn't stored in BlueDragon's file cache.
- It provides a level of obfuscation that helps protect your CFML source from prying eyes. It will be difficult (but not impossible) for someone to figure out how to de-serialize the Java objects that represent the CFML page, because those objects are proprietary to BlueDragon and their definition is not publicly available. But, even if someone does figure out how to de-serialize a precompiled template, all they'll get for their efforts is a bunch of Java objects--not your CFML source code.
Additional security for your CFML source code can be provided by creating "Encrypted" precompiled templates. When you create precompiled templates (either from the admin console or via a command-line tool), you have the option of encrypting the resulting serialized objects using industry-standard, commercial-grade encryption algorithms provided by the Java VM (see http://java.sun.com/products/jce/index.jsp for details).
The advantage of encrypting your precompiled templates is that it makes it extremely difficult (almost impossible) for anyone to decrypt the templates and reconstruct your CFML source. The disadvantages of encryption are that it significantly increases the file size, and eliminates the performance advantage of precompiling due to the extra processing required to decrypt the template.
There's more. Any CFML template encrypted using BlueDragon's built-in "default" key can be decrypted and run on any version of BlueDragon. However, you also have the option when creating precompiled, encrypted templates to have BlueDragon generate a unique key for that set of templates. Then, those templates can only be decrypted when that unique key is configured in the BlueDragon admin console. You can choose to create a single unique key and distribute that key to all your customers so they can run your code; or, you can create a unique key for each individual customer. It depends on what level of control and security you need.
What About the Former BDA Approach
Finally, for those of you who were interested in BDAs (BlueDragon Archives), here are the problems we discovered with BDAs, all of which are successfully addressed by Precompiled, Encrypted Templates:
- Deployment of BDAs is awkward. There are several issues here:
- The BDA only contains the dynamic contents of the application directory structure (".cfm", ".cfc", etc.) and not the static contents (".html", ".gif", ".js", ".css", etc.). This makes deploying an application somewhat disjoint: you have to deploy the original directory structure minus the dynamic content, and then also deploy and configure the BDA.
- Some of our customers only want to encrypt certain sub-directories of their application and not the entire application; some want to encrypt only custom tag libraries or CFCs. Again, this makes for a somewhat disjoint deployment using BDAs.
- The configuration required for BDAs can be confusing and error-prone for our customers or their customers.
- "Default document" processing doesn't work with BDAs. That is, if you configure "index.cfm" as the default document for a directory request (a request ending with "/"), it doesn't work if the index.cfm file is within a BDA.
- Microsoft IIS web server has an option to "check that file exists" before handing the request over to BlueDragon for processing, returning a 404 Not Found result to the browser if the file doesn't exist. This doesn't work for BDAs. (Other web servers may have similar options).
- With BDAs, it's not possible to update individual files for "patching" an application.
For our customers who are committed to using BDAs, we'll continue to support them as long as you need them (BDA support still exists in BlueDragon 6.1 and 6.2, we're just not going to publicize it anymore).
Precompiling from the Command Line
As mentioned above, it's possible to perform the precompilation from the command line, in addition to the Admin console option. The utility is called simply precompile (bat, exe or sh depending on operating system) and is found within the BlueDragon installation in either the bin directory of the java editions or the precompiler directory in BlueDragon.NET.
The precompilation feature is discussed further in the BlueDragon User Guide. In the 6.2.1 edition, it's in section 5.2.3.
We hope you find this new feature interesting and useful. As always, we look forward to your feedback to help us improve this feature and others supported by BlueDragon.