I wanted to take a few minutes to talk up a cool little tool that I started using a few weeks ago and have since come to rely upon.

smtp4dev (http://smtp4dev.codeplex.com/) is a dummy smtp server that, instead of sending email messages, stores them in a list for easy viewing and inspection.  Before I started using this tool, any time I wanted to test email sending for an application I had to, first of all, sanitize all of my data to make sure I didn't accidentally send messages to people that shouldn't get them, and then make sure any messages I needed to inspect were sent to my email account.  I would have to wait for messages to arrive in my inbox and deal with all of the test messages getting mixed up with my regular mail.  It was a big hassle, in other words.

An added benefit for me is that, since I access my regular mail through Gmail, I am able to easily open up the messages in Windows Live Mail (also a free download) which seems to replicate the way the email displays in Outlook.  For highly styled messages this is very important, since Outlook is a very popular client that has quite a few display quirks.

Comments (0)   Posted on July 29, 2010 9:45:06 AM EDT by David Hammond

We had a client trying to upload a 44mb file, and it was failing.  The ColdFusion page that that did the upload had a very high timeout setting, so I didn't think that timeout was the issue.  The ColdFusion administrator had a request limit set of 100MB (which I believe is the default).  What was up? 

It took a bit of googling to realize that IIS7 (the webserver on our Windows 2008 Server), had a default request limit of 30MB.  The solution is rather simple.  With IIS7, a web.config file can be used to set a variety of webserver settings, so I added one to the site that was having the problem.  Here are the contents of the file:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <security>
            <requestFiltering>
                <requestLimits maxAllowedContentLength="1024000000"/>
            </requestFiltering>
        </security>
    </system.webServer>
</configuration>

This sets the request size limit to 100MB, to bring it in line with ColdFusion.  This isn't the only thing that can be controlled with web.config.  For some information on how to tighten security on a site using web.config see this page: http://www.petefreitag.com/item/741.cfm

Comments (0)   Posted on May 3, 2010 1:44:47 PM EDT by David Hammond

Some background first...

I had the need to do diff of html content in a project I was working on, which brought me pretty quickly to DaisyDiff, a really nice Java-based utility.  DaisyDiff doesn't however, have a simple built-in function to do a diff of two strings.  There is a command-line option, which takes the paths of two files as arguments, and also a java api that take a number of java objects as arguments.  What I wanted was a function that took two strings and output the results, but DaisyDiff has no such simple function.

I don't really do java development -- that is I've done some in the past but it's been a while and it would probably take me some time to get my development environment up to snuff.  Besides, I didn't really feel like dealing with compiled code. 

A quick google search, of course, turns up CFX_CompareHTML and the JavaLoader version of the same thing.  So I used that, and it worked fine.  But it was using an old version of DaisyDiff, and it seemed to have some bugs with UTF characters and such.  What I really wanted to do was to use JavaLoader to load the current version of DaisyDiff.  After much stumbling around in the code, I found that the test suite in the DaisyDiff repository has exactly the function I wanted -- it compares two strings and returns the result.

So, long story short, I took the code from that function and pulled it into a CFC, using JavaLoader, and rewrote everything in CFML.  The result is the simple function I was after.

So anyway, here it is:

<cfcomponent hint="Wrapper for DaisyDiff" output="false">

    <cffunction name="Init" output="false" returntype="DaisyDiff">
        <cfargument name="daisydiffpath" hint="absolute path to daisydiff jar file" type="string" required="true">
        <cfargument name="javaloaderpath" hint="component path to JavaLoader.cfc" type="string" required="true">
        <cfset This.daisydiffpath = arguments.daisydiffpath>
        <cfset This.javaloaderpath = arguments.javaloaderpath>
        <cfreturn This>
    </cffunction>

    <cffunction name="Diff" output="false" returntype="string">
        <cfargument name="olderHtml" type="string" required="true">
        <cfargument name="newerHtml" type="string" required="true">

        <cfset var paths = [This.daisydiffpath]>
        <cfset var loader = createObject("component", This.javaloaderpath).init(paths)>
        <cfset var TransformerFactoryImpl =     loader.create("com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl")>
        <cfset var StringReader =                 loader.create("java.io.StringReader")>
        <cfset var StringWriter =                 loader.create("java.io.StringWriter")>
        <cfset var Locale =                     loader.create("java.util.Locale")>
        <cfset var StreamResult =                 loader.create("javax.xml.transform.stream.StreamResult")>
        <cfset var OutputKeys =                 loader.create("javax.xml.transform.OutputKeys")>
        <cfset var NekoHtmlParser =             loader.create("org.outerj.daisy.diff.helper.NekoHtmlParser")>
        <cfset var DomTreeBuilder =             loader.create("org.outerj.daisy.diff.html.dom.DomTreeBuilder")>
        <cfset var HTMLDiffer =                 loader.create("org.outerj.daisy.diff.html.HTMLDiffer")>
        <cfset var HtmlSaxDiffOutput =             loader.create("org.outerj.daisy.diff.html.HtmlSaxDiffOutput")>
        <cfset var TextNodeComparator =         loader.create("org.outerj.daisy.diff.html.TextNodeComparator")>
        <cfset var InputSource =                 loader.create("org.xml.sax.InputSource")>
               
        <cfset var finalResult = StringWriter.Init()>
        <cfset var result = TransformerFactoryImpl.Init().newTransformerHandler()>
        <cfset var sr = StreamResult.Init(finalResult)>
        <cfset var prefix = "diff">
        <cfset var cleaner = NekoHtmlParser.Init()>
        <cfset var oldSource = InputSource.Init(StringReader.Init(olderHtml))>
        <cfset var newSource = InputSource.Init(StringReader.Init(newerHtml))>
        <cfset var oldHandler = DomTreeBuilder.Init()>
        <cfset var newHandler = DomTreeBuilder.Init()>
        <cfset var leftComparator = "">
        <cfset var rightComparator = "">
        <cfset var output = "">
        <cfset var differ = "">
        <cfset var diff = "">

        <cfset result.setResult(sr)>
        <cfset result.getTransformer().setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes")>

        <cfset cleaner.parse(oldSource, oldHandler)>
        <cfset leftComparator = TextNodeComparator.Init(oldHandler, Locale.getDefault())>

        <cfset cleaner.parse(newSource, newHandler)>
        <cfset rightComparator = TextNodeComparator.Init(newHandler, Locale.getDefault())>

        <cfset output = HtmlSaxDiffOutput.Init(result,prefix)>
        <cfset differ = HTMLDiffer.Init(output)>
        <cfset differ.diff(leftComparator, rightComparator)>
        <cfset diff = finalResult.toString()>

        <cfreturn diff>
    </cffunction>

</cfcomponent>

Usage:

<cfset var daisy = CreateObject("component","cfc.DaisyDiff").Init(expandPath("../daisydiff-1.1/daisydiff.jar"),"Lighthouse.Utilities.javaloader.JavaLoader")>
<cfset var diff = daisy.diff(olderhtml,newerhtml)>

The result is html that has been marked up by DaisyDiff with special classes.  You can take that and style it in any way that you see fit.

I'm sure there are some refinements that could be done to this CFC.  The class name prefix, for instance, is hardcoded to "diff", and that could be changed if you need to use a different prefix.  Someone more familiar with the Java classes used here could find problems too, which I would welcome.

Comments (2)   Posted on March 29, 2010 4:37:47 PM EDT by David Hammond

MangoBlog is a sweet (ha ha) ColdFusion-based blog, but it doesn't currently support creating multiple blogs using the same codebase.  You can easily make a copy of the code and create another blog that way, but if you're looking at 3, 4, or more blogs, then it's going to start getting out of hand, especially if you want to share the same basic styles for all of the blogs.  (Styles can change, of course!)

One thing that I didn't hear suggested on the MangoBlog forums was to simply create a virtual directory on the webserver in order to create another blog using the same code as an existing blog, and that turned out to work really well.  I wanted to document the steps I took to set that up for the benefit of my future self and others.

Set up Application.cfc

The first thing is to set up Application.cfc to support multiple blogs.  At the top of Application.cfc I added this (my first blog was in a directory called "blog" and all the new ones are in other subdirectories):

this.blogid = ListFirst(cgi.SCRIPT_NAME,"/");
if (this.blogid is "blog"){
    this.blogid = "default";
}

Then I included the blogid in the application name:

this.name = "mango_#right(hash(GetDirectoryFromPath(GetCurrentTemplatePath())),50)#_#this.blogid#_v1_4_2";

Then I used that blogID in the OnApplicationStart:

<cfset facade.setMango(createobject("component",variables.componentsPath & "Mango").init(getDirectoryFromPath(GetCurrentTemplatePath()) & "config.cfm",      
    this.blogid,
    getDirectoryFromPath(getCurrentTemplatePath()))) />

With that initial setup, creating a new blog is a 3 step process:

1. Create new blog and blog author records, copying settings from the default blog

The sql below is what I used

DECLARE @blogid nvarchar(32),@basePath nvarchar(32)
SET @blogid = N'new_blog_subdirectory'
SET @basepath = N'/' + @blogid + N'/'

INSERT INTO BLOG_blog (id, title, description, tagline, skin, url, charset, basePath, plugins, systemplugins)
SELECT @blogid, title, description, tagline, skin, replace(url,'/blog/',@basepath), charset, @basePath, plugins, systemplugins
FROM BLOG_blog
WHERE ID = 'default'

INSERT INTO BLOG_author_blog (author_id,blog_id,role)
SELECT author_id,@blogid,role
FROM BLOG_author_blog
WHERE blog_id = 'default' and role = 'administrator'

2. Copy the blog settings in config.cfm

Make a complete copy of the node that starts "<node name="default">"  and change "default" to your new blog subdirectory name.  Since the config settings for all of my blogs are the same, it would be nice if I could just tell it to use the default configuration, but that doesn't seem to be possible without changes to the MangoBlog code.

3. Create a virtual directory in IIS

Just point the new directory to your original blog directory.  I assume that you can do the same thing in Apache, but I don't have much experience with that.

That's it!

Comments (3)   Posted on March 24, 2010 3:37:42 PM EDT by David Hammond

Lighthouse 3.0 introduces a new task manager that makes setting up and managing scheduled tasks for a website easier and more flexible.

The way it works is that Lighthouse automatically creates a master task in the ColdFusion administrator that runs every 5 minutes.  Whenever this master task runs, it looks for tasks in Lighthouse that are due to run and runs them.  One advantage of this is that no matter how many tasks are set up for a site, there is only one entry in the ColdFusion admin -- which makes managing multiple sites on the same server easier.  More importantly, it allows for more flexible and robust scheduling options than would otherwise be available.

The Lighthouse Task Manager is relatively simple.  Here is the screen to add a task:

Rather than set a url for the task, you must provide a cfc method to run for the task.  So you need to put your task code in a CFC method that is set to access="remote".  You would then specify the method as "cfc.MyCFC.MyMethod".

You can then specify the interval for the method, any prerequisites (other daily tasks that must be run before the current task is run), and the window of time during which the task should be run.

Most of these options are available in the ColdFusion task manager, but the option to set a prerequisite for a task is an important addition.  This allows you to set up any number of tasks to run at a particular time in the morning, and ensure that they will all run in the correct order, and also ensure that if a task fails, other tasks that depend on it are not run.

The task manager also keeps a log of every time a task is run.  The task method should return a string, which will be logged.  If the task produces an error, the task run will be recorded as unsuccessful, and the error message will be logged.  To log custom error messages, you will want to catch any errors and throw a custom error with the appropriate message.

The task manager is pretty new at this point, and hasn't gone through any trials by fire yet, but I'll be interested to see how it is used as more sites adopt Lighthouse 3.0.

Comments (0)   Posted on February 8, 2010 3:13:49 PM EST by David Hammond

I've run into a strange bug with CFC inheritance.  It definitely seems to be a problem in ColdFusion 8, and I would be interested to see if it's a problem in CF9 also, but I haven't started using CF9 yet.

The problem comes up if you extend a CFC of the same name that is in a different directory.  CFCs in different directories should be treated as completely different components, as far as I know, but something goes wrong if the file name is the same.  For a simple test case, I created 3 CFCs:

/test/Test1.cfc
<cfcomponent output="false">
    <cffunction name="Test" output="true">
        Super Test
    </cffunction>
</cfcomponent>

/Test1.cfc
<cfcomponent extends="test.Test1" output="false">
    <cffunction name="Test" output="true">
        Test
    </cffunction>
</cfcomponent>

/Test2.cfc
<cfcomponent extends="test.Test1" output="false">
    <cffunction name="Test" output="true">
        Test
    </cffunction>
</cfcomponent>

The first file is in a subdirectory, and the other two files are identical except for their names -- one of them is the same name as the first file, and the other one is different.

I created a fourth file with the following code:

<cfset CFC1 = CreateObject("component","test.Test1")>
<cfset CFC2 = CreateObject("component","test.Test2")>
<cfoutput>
<p>#CFC1.Test()#</p>
<p>#CFC2.Test()#</p>
</cfoutput>

What would you expect this file to output?  I would expect:

Test
Test

Instead, I get:

Super Test
Test

In other words, even though /Test1.cfc overrides the Test function, it is ignored in favor of the function in /test/Test1.cfc.  Test2.cfc, on the other hand, works correctly.

My first question, of course, is: Have I missed something?  This sure seems like a glaring bug to me.

Update:
If the Test function is set to access="remote" and called directly from the browser like this:
/Test1.cfc?method=Test
Then it produces "Test" as expected.  All other methods I have tried of calling the function produce "Super Test".  Certainly a head-scratcher.

Comments (1)   Posted on January 25, 2010 8:33:18 PM EST by David Hammond

This post is related to the tokenized auto-complete jQuery plugin available at http://loopj.com/2009/04/25/jquery-plugin-tokenizing-autocomplete-text-entry/.  It is a great plugin.  There are several comments in the discussion on that page regarding the following mods to the plugin. 

• Use of local filtering instead of AJAX.  This makes sense when you have a smaller, pre-defined list of values to select from.
  
  
• Only allowing a token to be selected if it is not already in the list of selected tokens.

It took me a few hours to update the plugin to implement these mods, so I wanted to share the results.

Here is a demo of the plugin modified to for the above items.  Ideally, the plugin would be updated to allow local and remote lookups.  However, I did not have time to implement in this manner, so my version solely works for local lookups.

View Demo

Comments (0)   Posted on November 4, 2009 1:26:58 PM EST by David Hammond

It's gotten so I can't think about writing any code without fretting about security while I'm doing it.  I know, I know, that's a good thing.  Still one does long for the old days when the makers of small to medium-sized websites could get away with lax security just because the big sites had enough security holes to keep the hackers busy.  And those hackers didn't have as many automated tools to make hacking lots of sites easier.

Anyway, those days are long gone and none of us has to be labeled paranoid, because they really are out to get us.

So, on my security checklist was to start using HttpOnly cookies for potentially sensitive cookies (like those related to login).  HttpOnly cookies have been supported for a while by Internet Explorer, and Firefox has recently started supporting them.  What's good about HttpOnly cookies is that their values can not be accessed through javascript, which stops a variety of cross-site-scripting attacks.  For more info, here is a good page:

http://www.12robots.com/index.cfm/2009/1/5/mmmmMMmmmmmmm-Cookies--Security-Series-12

The problem that comes up immediately for a ColdFusion developer is that the CFCOOKIE tag does not support httponly cookies.  This seems like a gross oversite, especially since it should be very easy to implement.  In order to use httponly cookies, you need to use the CFHEADER tag to to write the specially formatted cookie header to the browser.  I looked around but couldn't find anyone online that had created a function that handled all of the functions of CFCOOKIE with the addition of httponly.  Anyway, here is what I came up with. 

<cffunction name="SetCookie" hint="Replacement for cfcookie that handles httponly cookies" output="false" returntype="void">
    <cfargument name="name" type="string" required="true">
    <cfargument name="value" type="string" required="true">
    <cfargument name="expires" type="any" default="" hint="''=session only|now|never|[date]|[number of days]">
    <cfargument name="domain" type="string" default="">
    <cfargument name="path" type="string" default="/">
    <cfargument name="secure" type="boolean" default="false">
    <cfargument name="httponly" type="boolean" default="false">
    <cfset var c = "#UCase(name)#=#value#;">
    <cfset var expDate = "">
    <cfswitch expression="#Arguments.expires#">
        <cfcase value="">
        </cfcase>
        <cfcase value="now">
            <cfset expDate = DateAdd('d',-1,Now())>
        </cfcase>
        <cfcase value="never">
            <cfset expDate = DateAdd('yyyy',30,Now())>
        </cfcase>
        <cfdefaultcase>
            <cfif IsDate(Arguments.expires)>
                <cfset expDate = Arguments.expires>
            <cfelseif IsNumeric(Arguments.expires)>
                <cfset expDate = DateAdd('d',Arguments.expires,Now())>
            </cfif>
        </cfdefaultcase>
    </cfswitch>
    <cfif IsDate(expDate) gt 0>
        <cfset expDate = DateConvert('local2Utc',expDate)>
        <cfset c = c & "expires=#DateFormat(expDate, 'ddd, dd-mmm-yyyy')# #TimeFormat(expDate, 'HH:mm:ss')# GMT;">
    </cfif>
    <cfif Len(Arguments.domain) gt 0>
        <cfset c = c & "domain=#Arguments.domain#;">
    </cfif>
    <cfif Len(Arguments.path) gt 0>
        <cfset c = c & "path=#Arguments.path#;">
    </cfif>
    <cfif Arguments.secure>
        <cfset c = c & "secure;">
    </cfif>
    <cfif Arguments.httponly>
        <cfset c = c & "httponly;">
    </cfif>
    <cfheader name="Set-Cookie" value="#c#" />
</cffunction>

It's actually pretty simple, with the expires portion of the header being the only thing that required a little work.  I have attempted to mimic the CFCOOKIE functionality so that this can be used more or less as a simple replacement for that tag.  Here's an example of usage:

<cfset SetCookie(
    name="logintoken",
    value="sometoken",
    secure=true,
    httponly=true)>

I hope this proves helpful to others.

Comments (2)   Posted on October 8, 2009 3:13:19 PM EDT by David Hammond

We have a production server that is set up with Filezilla FTP server.  For obvious security reasons, we require an SSL connection to the server.  This works fine with most FTP clients, and can also be used through Aptana (though only the Pro version supports FTPS and SFTP).  Aptana has some really nice FTP editing and synchronizing capabilities, but they are, at this time, a bit buggy.  I wanted to document some of the hurdles I went through to get them working so that I can remember for next time, and also possibly help out other people struggling with the same things.

The first big problem I ran into is that, for whatever reason, the SSL certificate I have set up on my server is not recognized automatically by Eclipse.  The error message in Eclipse is not helpful at all, but what it comes down to is that I have to install my certificate in the java key store that is being used by Eclipse.  There is a command line tool to install a certificate, but I recently came across an Eclipse plugin that makes this much easier.  It's called Keytool (http://keytool.sourceforge.net/).  If you like GUIs, you will appreciate it.  If you prefer command line tools, more power to you!  Here's the steps I took (I apologize if I gloss over some of the steps -- leave a comment if you need any more info about any of them):

• Open a website that uses the SSL certificate in Firefox.
• Export the certificate as "X.509 Certificate with chain (PEM)"
• Use the Keytool plugin to import the certificate into your java keystore.  
• Restart Eclipse/Aptana

So far so good.  Next, to set up the FTPS connection in Aptana. 

• In the FTPS site properties, select the connection type of FTPS
• In Advanced Properties, set the port to 990, select passive mode, and select the security type of TLS.

Those are the settings that worked for me, at least.  One strange thing I noticed is that if I open up the connection properties again and then click the Cancel button, the Advanced Properties settings are cleared out.  This is one of the Aptana bugs I am referring to.  I think Aptana is great, but is definitely a little polish lacking here and there.

Comments (0)   Posted on October 6, 2009 2:40:19 PM EDT by David Hammond

I recently finished a redesign project, and there were some interesting challenges that came up that I thought I would write about.

To start off, there were the menus.  The site has an obligatory drop-down menu at the top, and a similarly styled menu on the left.  Here's a look at the drop-down menu:

As you can see the items in the menu have a little caret on the left, they turn a darker gray on mouseover, and certain items (members-only ones) have a special star icon on the right.  There are also submenus with the same style.  I'm not going to talk about the specific javascript implementation that I used for the drop-down (I used a slightly modified version of the jQuery plugin jdMenu to get it done -- http://jdsharp.us/jQuery/plugins/jdMenu/), but will instead address how the styles are implemented, which was a bit trickier than you might think.

The html for the menu is a simple nested unordered list:

<ul>
  <li><a href=[url]>20 Clubs</a></li>
  <li><a href=[url] class=star>Build-PAC Contributors</a>
    <ul>
      <li><a href=[url] class=star>BUILD-PAC Fundraising</a></li>
      ... etc ...
    </ul>
  </li>
  ... etc ...
</ul>

Nice and clean and accessible.  But the style has to be pixel perfect too, of course.

When I got the menu from the designer, the caret and the star were implemented with a single background image.  That made sense to some extent.  You can only have one background image per element.  And I can't use the <li> for one of the background images because the only elements that supports the hover is the <a> tag.  And I needed to use the a:hover css selector to make the items turn dark gray on mouseover.

Fine.  But that really makes things a bit complicated and inflexible.  What if I need to adjust the width of the menus (which did indeed happen several times during the redesign)?  I would then need to recreate those background images with the correct width.  I know just enough Photoshop to do that kind of thing, but it's really annoying.

Finally it occurred to me that there's really no reason that the <a> tag is the only one that can do a hover.  With javascript, I could capture the hover for any element.  What is more, jQuery made this very easy to do.  I added this to my page:

$("td.leftnav ul li").hover(function(){
    $(this).addClass("hover")
  },function(){
    $(this).removeClass("hover")
})

(Okay that bit of code applied to my left navigation menu.  jdMenu actually took care of this for my top nav by adding a "jdm_hover" class.)

So with that little bit of code, I was free to set the caret as the background of the <li>, and set the star as the background of the <a>, and let the hover of the <li> take care of the background color change.  And when I inevitably got that call to change the width of the menus, it was a simple change in the stylesheet.

Comments (0)   Posted on September 22, 2009 3:08:41 PM EDT by David Hammond