Sumo Consulting^2.0

Ran into an unusual problem last week while upgrading Commonspot 3.2 SP2 to a 3.2 SP4 and CFMX 6.0 to CFMX 6.1. Thought I'd drop it into the ole blog in case someone else runs into this problem. After the upgrade everything seemed fine except replication. Having dealt with a number of replication problems in the past I wasn't totally shocked by this, but the error wasn't one I'd seen before. In the application.log file, I uncovered the following:

"Error","jrpp-47","05/19/04","10:29:38","CommonSpot","CFID, CFTOKEN contains invalid characters. This exception is caused by either broken links, or security attacks. The invalid id is 370db970662a6471%2D9D91146A%2D96A6%2DEFAB%2DDC215EC73B22393D The specific sequence of files included or processed is: /xxx/xxx/commonspot/sync/sync-process-requests.cfm"

After decoding the URLFormatting of the string, I found that the invalid CFTOKEN being passed was 370db970662a6471-9D91146A-96A6-EFAB-DC215EC73B22393D. It's pretty apparent that this is a UUID with some sort of rouge data appended to the front of it.

The reason that this might throw a ColdFusion error is somewhat documented in the following forum post by Christian Cantrell. From the looks of it, anytime ColdFusion gets a CFTOKEN or CFID value in a format that it doesn't expect, it blows up. In this specific case, it may have been because the CFTOKEN contained lowercase text, or perhaps because the format of the string was unexpected. Either way, it made CF break.

So I knew why ColdFusion blew chunks, and just had to wait for Paperthin to get back to me on why Commonspot might have passed this CFTOKEN value during replication.

Side note: For those who've not dealt with Commonspot's content replication before, it's essentially a process where an authoring server "replicates" approved content to one or more "target" content servers. There are a few choices on how to have Commonspot move the data, including FTP and HTTP (CFFTP and CFHTTP). The content to be replicated is zipped up and transferred to the target server, then unpacked and distributed to it's location in the database or file system.

Back to the problem - I finally heard back from Paperthin about the root case of this issue. Turns out that Commonspot tracks CFTOKEN/CFID pairs within the replication process so that the repeated requests between the authoring server and target server(s) don't startup a buncha phantom sessions. Somewhere along the way, their tracking of the CFTOKEN got munged and the replication process started feeding the invalid value to the target server. This halted replication in it's tracks.

Paperthin sent over a couple of patches to solve the problem, and I also ended up turning off the "Use UUID CFTOKEN" option in CFMX's admin. One of those two things fixed the problem, though I am uncertain which it was. Hopefully this little tidbit of information will help out someone else in the future...

• Comments (0)