document.lastModified in Google Chrome

It's fairly common to put something like document.write(document.lastModified); on a web page to display the date and time the document was last updated. This works fine in IE and in FireFox and seems like straight forward cross browser compatible and is kosher according to "JavaScript: The Definitive Guide, 5th ed."

Chrome doesn't like it. Now, for cross browser compatibility, you've gotta use
document.write(Date().toLocaleString(document.lastModified));

I'm not sure what's going on here. The Chrome JavaScript console shows document.lastModified as undefined. Maybe it's a WebKit thing. I'll have to see what Safari does.

Alright everyone... update your scripts!

Fixing ColdFusion's issues with method="get" and multiple select boxes

ColdFusion doesn't seem to like forms with method="get".
I've been developing a simple search tool with a multiple select box to specify some of the search criteria. Because I wanted to make the results linkable I used method="get" in the form.
The browser with return the multiple select values like so:
?select1=val1&select1=val2
But ColdFusion will see it as url.select1 = "val2". Only the last select will be present in the url scope.
To solve this problem we've got to bypass the url scope and grab the values directly from the CGI.QUERY_STRING like so:

<cfset get=StructNew()>
<cfloop index="keyvalpair" list="#CGI.QUERY_STRING#" delimiters="&">
<cfset key=ListFirst(keyvalpair, "=")>
<cfset keyval=URLDecode(ListLast(keyvalpair, "="))>
<cfif not StructKeyExists(get, key)>
<cfset get[key]="">
</cfif>
<cfset get[key]=ListAppend(get[key], keyval)>
</cfloop>

Now the get structure will contain everything in the url scope plus a comma separated list of values from the multiple select boxes.
From our example above: get.select1 = "val1,val2".

Large strings in ColdFusion

ColdFusion is great. Generating complex html with CF is very easy but sometimes I'm not interested in creating a complex html document but, rather, I need to create a large and complex string and maybe I want to write it to a file.
To work with strings in CF as easily as I work with html I wrote a very simple custom tag, <cf_BlockToString>.
The tag works like this:

<cf_BlockToString var="myVar">
This is a bunch of text where I'm able to "quote" things and #pound# out the special characters without escaping.
<cfset newVar="I can still do normal CF stuff too."> <cfoutput>#newVar#</cfoutput> </cf_BlockToString>

<cfoutput>#myVar#</cfoutput>

The quick and dirty version (no error checking) of BlockToString.cfm is:

<cfif thisTag.ExecutionMode is 'end'>
<cfset Caller."#Attributes.var#" = thisTag.GeneratedContent>
<cfset thisTag.GeneratedContent = "">
</cfif>

Have fun.

SSL Woes with WebSite Pro

I run a web site that uses a site certificate that we buy from VeriSign. That certificate came up for renewal last month so I went through the usual process to buy a new certificate: Put in a purchase request, wait for approval, generate a certificate request, upload the certificate request to VeriSign, enter the credit card info, and wait for the new certificate to arrive in my inbox.

Every year previously it was as simple as that. But this year VeriSign rejected my certificate request on the grounds that it was a 512 bit request and that the minimum it would accept was a 1024 bit request. So, I went to my server and opened up the WebSite Pro server management tool to find the option for generating a 1024 bit request. It didn't exist. Apparently, with WebSite Pro, you can have as many bits as you want as long as it's 512.

Without any way to get WebSite Pro to make a 1024 bit certificate request I went back to VeriSign to find the option to upload a 512 bit request. It didn't exist. So, I clicked the button to request a chat with tech support and got someone to chat with me after a few minutes. I explained my situation and his first suggestion was to RTFM and find out how to generate a 1024 bit certificate request. Okay, I humored him and perused the help file for a few minutes after which I reported back that such instructions were absent from TFM.

Next, I asked him how to get VeriSign to accept a 512 bit request. He reported back that VeriSign has adopted "best practices" requiring a minimum of 1024 bits. I asked if this was a new best practice since one year ago 512 bits was not a problem. Indeed, yes, sometime during 2008 it became a requirement. Looks like their best practices did not include informing the WebSite Pro administrators that their servers would no longer be supported by VeriSign.

I told my tech support chat buddy that I was, therefore, not able to plunk down $2500 for a three year certificate. "What's your telephone number? When is a good time to have someone contact you?" Best practice does include keeping a $2500 sale alive.

A short while later I received a call from the saleswoman who had been calling me every week for the past 2 months to remind me that my certificate was expiring and offering help to get it renewed. I explained my situation again and she was eager to transfer me to tech support where I was on hold for way too long. Lunch hour came around while the hold music was playing and the cafeteria seemed more promising than the hollow hope of VeriSign tech support so I hung up with a little over one week to go until my site certificate expired.

In 2001, ownership of WebSite Pro changed from O'Reilly to Deerfield and in early 2004, Deerfield dropped sales and support for WebSite Pro all together. It's now five years later and we're still running this dinosaur. This little VeriSign issue is a good reason (amongst others) to move from WebSite Pro to web server that is still supported.

The decision was made to replace WebSite Pro with IIS. When I say that I am the administer of this server what I mean is that I am an administer with some (not all) rights. I did not set it up and I have no control over the security lock-down policies imposed on the machine. I spent four days trying to get IIS installed and working. The day before the VeriSign certificate was to expire I was able to achieve marginal success. IIS would serve static pages but asp was broken and I could not get ColdFusion (an essential part of the server) installed and working. I could, however, generate 1024 bit certificate requests and so I did.

Closing time was fast approaching so I emailed the certificate request to the credit card holder and visited her office to finally buy the new site certificate. I logged into VeriSign and uploaded the new certificate request but this time Verisign didn't like the fact that my certificate request abbreviated the state rather than spelling it out in full. So... I went back to the server, canceled the original certificate request, and generated another one with the state spelled out in full. I logged back into VeriSign and uploaded the certificate request and this time it was successful. We entered the credit card info and paid.

Now that I had completed that, I had to get back to the task of getting the server working with IIS. I tried various iterations of uninstalling and reinstalling IIS and uninstalling and reinstalling ColdFusion to no avail. Each uninstall or reinstall required a reboot which took a full 10 minutes just to reboot. It was getting late, now after hours, and my server was broken. My goal was now to forget IIS and put it back working with WebSite Pro which took another round of uninstalling and reinstalling ColdFusion. The server was finally working again so I called it a day but the clock was still ticking on the site certificate installed in WebSite Pro.

The morning of expiration day arrived and my boss called me while I was on my way to the office. It turned out that there were some ColdFusion configuration issues that I didn't catch the previous night and some of the users now couldn't get their job done. When I arrived I found the new site certificate from VeriSign in my inbox and I quickly fixed the configuration problem and had to wait until 2pm when most of the daily work would be done and the server wouldn't been needed again for a while. During that time I was able to install the new certificate in IIS and it occured to me that I could export the certificate from IIS and possibly import it into WebSite Pro.

Exporting the certificate as a .pfx file was no problem. But WebSite wants the certificate in .pem format. Using OpenSSL for Win32 I was able to convert the certificate with
>openssl pkcs12 -in cert.pfx -out cert.pem -nodes
and successfully imported it into WebSite Pro.

Now the server is running as before with a certificate that expires in three years and we still need to get rid of the old unsupported WebSite Pro.