Twitter: raymondcamden

Address: Lafayette, LA, USA

Fixing the Facebook Problem, and why one ColdFusion feature needs to die...

09-21-2007 19,772 views ColdFusion 45 Comments

I spent some time today working with Anthony Webb and Ben Nadel on a rather interesting problem. Anthony was trying to build a Facebook application. (More info may be found at the cftalk thread.) Facebook's test application sends a form POST to the file you want to respond to it's request. This form POST includes a set of form variables. Here are two of the variables:


Among other variables as well. The problem was though that he would get an error whenever the POST was made. Why? Well, there is an ancient ColdFusion feature that lets you do form validation with specifically named form fields:

Validating form fields using hidden form fields

No one uses this feature. Seriously - no one. In fact, the only time you hear it mentioned is when someone accidentally names a form field wrong and trips this validation. When I said in the blog title that this was a feature that needed to die - I was only being partially sarcastic. I hope that ColdFusion 9 will either dump this "feature" or at least let us turn it off with a Application.cfc variable. (I know ColdFusion is all about the backwards compatibility, but come on, it's time to dump this along with parameterExists!)

Ok - so enough ranting. We can't turn it off - so what do we do? Well the first thing I tried was a check in onRequestStart. Nope - even though this is supposedly "before" the request, it isn't before ColdFusion's magical form check. I then tried onRequest. No dice there.

So I knew that there was a cferror tag just for this type of error - so I tried onError. Success! I was able to trap this error and check for a Facebook post and then simply include the file to handle the request:

view plain print about
1<cffunction name="onError" returnType="void" output="true">
2    <cfargument name="exception" required="true">
3    <cfargument name="eventname" type="string" required="true">
4    <!--- look for FB post --->
5    <cfif findNoCase("Form entries are incomplete or invalid", arguments.exception.message)
6        and
7     structKeyExists(form, "fb_sig")>

8        <cfinclude template="testi.cfm">
9        <cfreturn>
10    </cfif>                
11    <cfdump var="#arguments#">

This worked fine, but was a bit ugly. Here is where Ben Nadel came up with his solution. Apparently if you muck with the Form scope in the Application.cfc constructor, you can fix the problem. Remember that the constructor is any area outside of the methods. So by just adding this for example:

view plain print about
1<cfset structDelete(form, "fb_sig")>

The problem would go away... along with the form field. I liked this solution better than my onError code, so wrote up a quick UDF that could be called from the constructor area. My thinking was that this would keep your constructor area a bit more tidier.

So now you can add:

view plain print about
1<cfset fixFacebook()>

And run the method I wrote. But here is where things got wonky. For my solution I decided to simply rename all form keys from FOO to FOO_X. I didn't need to rename them all, but I figured doing them all would make it simpler. My code though continued to throw the error. I dumped the form scope and saw that all my fields were renamed, but I still got NPEs with the form validation. Freaky.

So I then changed to setting the old form fields to an empty string, and that for some silly reason worked. Here is what I ended up with:

view plain print about
1<cffunction name="fixFacebook" returnType="void" output="false" hint="Attempt to fix a facebook post.">
2    <cfset var f = "">
3    <!--- detect if FB is posting to us --->
4    <cfif structIsEmpty(form)>
5        <cfreturn>
6    </cfif>
7    <!--- check for one key now- maybe check for more later? --->
8    <cfif structKeyExists(form, "FB_SIG")>
9        <!--- loop through and rename all to _x --->
10        <cfloop item="f" collection="#form#">
11            <cfset form[f & "_x"] = form[f]>
12            <cfset form[f] = "">
13        </cfloop>
14    </cfif>

Maybe overkill a bit - but I'm the kind of guy who would probably write a method to cross the street.

Anthony correctly then made all of this a lot simpler with this code snippet, no UDF, but nice and tight and works fine with Facebook:

view plain print about
1<cfif structKeyExists(form, "FB_SIG")>
2<cfset form.FB_SIG_FIX = form.FB_SIG>
3<cfset form.FB_SIG = ''>

So - anyone writing Facebook applications in ColdFusion yet? I think I may give it a whirl now.

p.s. So I obviously named my title a bit over the top - but this weekend I'll be blogging on something I saw on DZone - specifically - what features should be avoided in ColdFusion. Maybe none should be. Maybe you have you own pet peaves. Think about it and be ready to post.


These comments will soon be imported into Disqus. To add a comment, use Disqus above.
  • Commented on 09-21-2007 at 5:27 PM
    Hey Ray, Glad the gladiators are looking into this :). I have been working with Anthony on this also and supplied him my starter template for Facebook, which of course works in CF7:

    I don't have a CF8 server to test on as yet but two things:

    1. I am quite certain that Anthony's solution that you quoted will not work. I think he was summarising the same thing as you did with the loop on all form fields, i.e.

    <cfset form[f & "_x"] = form[f]>
    <cfset form[f] = "">

    2. If this solution works in CF8 then great! It does not work in CF6.1-7 though. Instead, you must use this (which doesn't work in CF8):

    <cfset form[f & "_x"] = form[f]>
    <cfset StructDelete(form,f)>



    p.s. I'm just reworking my template now to reflect the CF8 issues, will be publishing it somewhere proper soon.
  • Commented on 09-21-2007 at 5:30 PM
    I must aplogise, Anthony was entirely correct and now I see why ;)

    Awesomeness all round!
  • Commented on 09-21-2007 at 6:45 PM

    Not sure you if were aware or not but when you use <cfinput type="text" validateAt="onServer" /> ColdFusion generates those exact same tags (hidden fields). So I wouldn't necessarily say nobody is using it, they just may be using it and not know. I know you despise built-in CF validation though. I have yet to have anyone give any valid arguments against it so I would be curious in knowing why it is "evil"
  • Commented on 09-21-2007 at 7:09 PM
    Why it is evil, by Dominc Watson.

    If an external application sends you a post request containing form fields that match the server-side validator criteria, an error will most likey be thrown. As a 3rd party developer, you may have no control over the names of those post variables and have to hack around it as pointed out in this Facebook example.

    If there was a switch to turn it off, or an interface to change the naming rules, I wouldn't have a problem with it.
  • Commented on 09-21-2007 at 8:50 PM
    Yeah, I use validateat some. It has its own bug too. If you run without JS, submit the form, it presents you with a link on the subsequent error page, which is a JS link. It doesn't take you back because you have JS turned off! :)

  • Commented on 09-21-2007 at 9:59 PM
    Ray, thanks for the info! I'm about to start prototyping a Facebook app this weekend and I just know that would have had me tearing my hair out.
  • Commented on 09-21-2007 at 10:01 PM
    TJ, in the example you gave, you are specifically asking for server side validation. That is different than someone accidentally naming their fields in such a way as to trigger this behavior.
  • Commented on 09-22-2007 at 8:33 PM
    Instead of pulling your hair out you could have looked around;

    Do check out this in a few days:
    I haven't run in to any CF7/8 problems per say. I'm attempting to 'wrap up' the various facebook quirks so we can just get on and build CF apps. Wooo.
  • Commented on 09-22-2007 at 9:24 PM
    Heh, speaking for myself, but I bet Ben N would agree, it was more fun trying to solve the problem myself. ;)
  • Commented on 09-22-2007 at 9:27 PM
    Of course :)
    Looking again at that post, you were there anyway ;)
  • Commented on 09-23-2007 at 7:25 AM
    I wouldn't sy that nobody uses the built-in server side validation. It can actually be quite a time saver for folks. hat said, I agree entirely that it'd be nice to be able to turn it off.
  • Commented on 09-23-2007 at 11:05 AM
    I definitely would agree :) Solving problems is much for fun than looking them up. Plus, a problem solved is much better remembered than a solution learned.
  • Commented on 09-23-2007 at 3:35 PM
    For anyone looking at building Facebook apps using FBML, the headache has been borne for you:

    I made a final version of this yesterday after fixing the bug mentioned in this article (it was working before with CF7)

  • Commented on 09-27-2007 at 3:59 PM
    HA! I had this same problem a very long time ago, must be on CF5 as there were no CFC's back then and I solved pretty much the same way but using application.cfm
    I also did actually figure out how to disable this validation check on the server, but even if I could remember how I did it wouldn't on current version of CF, so I wont bother trying to remember :-)
  • Commented on 11-15-2007 at 10:13 AM
    I've been ranting about this since CF5 and every release this auto validation has crept up and bit me somewhere.
    I personally think its rude imposing such a 'feature' on people without asking. Not to mention this without such hacks this renders CF almost unusable for 3rd party integration as you never know what will hit you and when...
    I just can't get why nobody ever did anything about it. A simple switch to turn this off from cfadmin (or another bloody hidden form field) is all that's needed!
    This makes CF looks so silly...
  • Tim #
    Commented on 12-13-2007 at 2:32 PM
    I am still getting a 'Form entries are incomplete or invalid.' response when using Dominic's template application. I've literally changed nothing in his template except for putting in my api key, secret key, and fixing the name in the <cfapplication> tag. I'm using CF 8 - any ideas?
  • Commented on 12-13-2007 at 3:13 PM
    Hey Tim, are you using the very latest version downloaded from Riaforge?

    If so, you can mail me at watson dot dominic at googlemail dot com. Maybe we can work it out (this beast never seems to die!).

  • Tim #
    Commented on 12-13-2007 at 3:15 PM
    Yup, sure am - I'll shoot ya something.
  • Commented on 12-17-2007 at 2:06 AM
    Also watch out for FORM.FB_SIG_PROFILE_UPDATE_TIME.
  • Commented on 12-17-2007 at 2:33 AM
    Actually, what is great about Anthony's simple fix is that this newish field is not a problem unless there is also a form field called FB_SIG_UPDATE_PROFILE.

    It is down to the way the validation works. i.e. You can submit this form without causing an error:

    <h1>Facebook test</h1>
    <cfif IsDefined('form.fieldnames')>
       <cfdump var="#form#">
    <form action="" method="post">
       <input type="hidden" name="FB_SIG_TIME" value="646574.413">
       <input type="submit" value="Test it!">

    If you do this however, you get the validation error:

    <h1>Facebook test</h1>
    <cfif IsDefined('form.fieldnames')>
       <cfdump var="#form#">
    <form action="" method="post">
       <input type="hidden" name="FB_SIG_TIME" value="646574.413">
    <input type="hidden" name="FB_SIG" value="646574.413">
       <input type="submit" value="Test it!">

    This demonstrates that the _TIME fields are not being validated, it is any field with the same name WITHOUT the _TIME that gets validated. If you blank that field in Application.cfm it will pass the validation.

  • Huge #
    Commented on 01-21-2008 at 4:59 AM
    I solved the problem with:

    <!--- 1. cf6+ tries server-side form validation on various form field names, fix: --->
       <cfset s_trouble = "integer,float,range,date,time,eurodate,key,expires,added,friends,canvas,user,method,fieldnames,fix">
       <cfloop list="#StructKeyList(form)#" index="formField">
          <cfif ListFindNoCase(s_trouble, ListLast(formField,'_'))>
             <cfset StructInsert(form, formField & '_CFFIX', form[formField])>
             <cfset StructDelete(form, formField)>
  • Huge #
    Commented on 01-21-2008 at 5:15 AM
    it was an error, i had a cfabort.

    Sorry, i continue with it.
  • Huge #
    Commented on 01-21-2008 at 8:03 AM
    Now I found a solution:

    Maybe some of ours have in Application.cfm(cfc) this code:

    <cfif StructKeyExists(form, "fb_sig")>
       <cfinclude template="fb_post.cfm">
       <cfinclude template="fb_get.cfm">

    And when CF procces de page, load de index.cfm page.

    It will be the normal processing, but I dont know why, but if you write this:

    <cfif StructKeyExists(form, "fb_sig")>
       <cfinclude template="fb_post.cfm">
       <cfinclude template="fb_get.cfm">

    <cfinclude template="index.cfm">

    The page loads correctly... and why?? I dont know, but it loads....

  • Commented on 01-21-2008 at 8:26 AM
    Hey Huge, looks like you're using the Facebook starter kit. You shouldn't need to do anything. As mentioned in this blog, the fix you are using crashes in CF8. The most straightforward solution is to do this in Application.cfm/cfc (works in 6.1 - 8):

    <cfif StructKeyExists(form, "FB_SIG")>
    <cfset form.FB_SIG_COPY = form.FB_SIG>
    <cfset form.FB_SIG = "">

    If you download the latest version of the starter kit, this fix is implemented and it should work straightaway for you.

    You may need to rename application.cfm to Application.cfm if you are having problems. I am fixing this now.

  • Huge #
    Commented on 01-22-2008 at 1:15 AM

    I have downloaded the latest version and I amd going to test it.

    Sorry from my english, i write from spain ;)
  • Commented on 09-30-2008 at 1:37 PM
    How about playing hide and seek with the variables.

    <cfset = "sep09helloworld">
    <cfset url.form = structnew()/>
    <cfset structappend(url.form,form)/>
    <cfset structclear(form)/>
    <cffunction name="onRequestStart">
    <cfset structappend(form,url.form)/>
    <cfset structdelete(url,"form")/>

    This application.cfc will store them in URL as a struct (which is left alone), then retrieve them from URL before processing the request. You won't need to change code on either end of your app.
  • Ray Varner #
    Commented on 07-23-2010 at 5:52 PM
    I've just dropped into your blog post linked from Adobe devnet. Great article by the way. I've not had the chance to experiment with this issue but I do have a question:

    Can the exception be caught in the onError() method in application.cfc? From your posting

    if (arguments.exception.rootCause eq "coldfusion.runtime.AbortException") {return;}

    Could a similar technique be used? "coldfusion.runtime.ValidationException" ... or whatever CF calls in the error.
  • Commented on 07-24-2010 at 6:57 PM
    No Ray - and that's what made tis so much a pain - it was near impossible to avoid.

    CF9 allows you to turn it off though.
  • Commented on 08-03-2010 at 1:01 PM
    Many thanks, to all involved!
    I love how a 2007 post just solved my 2010 problem.
    Still on CF8 but even so, a three year old "bug" in the web world? Ancient history, or so you would think!
    Wonder if the FB developers through this in as a knock against CF?
  • Commented on 09-09-2010 at 4:42 PM
    I turned serverSideFormValidation off in application.cfm but I'm still getting the "Form entries are incomplete or invalid" error coming from Facebook. Any other ideas?
  • Commented on 09-09-2010 at 4:50 PM
    Can you get more of the error? It may be something else.
  • Commented on 09-09-2010 at 4:52 PM
    Same error from the FB_SIG_TIME form field:
    Form entries are incomplete or invalid.
    Go back and correct the problem.
  • Commented on 09-09-2010 at 4:53 PM
    And you are on CF9 I assume?
  • Commented on 09-09-2010 at 4:55 PM
    Yes, 9.0.1. I even restarted CF to make sure the new application setting was in place. This is what I added to cfapplication: serverSideFormValidation="NO"
  • Commented on 09-09-2010 at 4:57 PM
    Can you pastebin the entire file so I can see? Also, can you temporarily try rewriting in App.cfc? Maybe this feature is broken in app.cfm, which is pretty much deprecated to be honest.
  • Commented on 09-09-2010 at 5:07 PM
    Probably can't. The code is dynamic, user-generated code that is included in a customer's Facebook site and submits back to their website which is run on our system. This is our main app so I can't switch to app.cfc for testing. I can't find the Adobe CF bug website to search...
  • Commented on 09-09-2010 at 5:11 PM
    Hmm, well, I'm out of answers. :) May want to see if trusted cache is turned on.
  • Commented on 09-10-2010 at 8:55 AM
    Ray, is there an official bug site for CF? I'd like to search and see if this listed. Thx
  • Commented on 09-10-2010 at 8:58 AM
  • Commented on 09-10-2010 at 9:07 AM
    Thanks. I found that site, but it kept forcing me to CF Builder bug site yesterday. Worked today, posted the bug, and saw your post recommending Adobe adds the feature. Guess you forgot to say "add the feature AND make it functional"!
  • Commented on 09-10-2010 at 9:13 AM
    Well, to be clear, it does work for me. But I've only tested with Application.cfc.
  • Commented on 09-10-2010 at 9:17 AM
    Actually, it may be something else. I just tested on CF901 and it worked as expected. Here is my application.cfm:

    <cfapplication name="ssformtest" serversideformvalidation="false">

    and here is test.cfm:

    <form action="test.cfm" method="post">
    <input type="text" name="name_required">
    <input type="submit">

    as soon as I toggle false to true, it triggers, and going back makes it not trigger.

    So perhaps you have something else going on? Maybe another application.cfm in the request is resetting it.
  • Ofeargall #
    Commented on 03-03-2011 at 4:20 PM
    Ray, I just implemented this on a first-time FB form for one of my clients. Worked like a charm on CF8. Thanks for working through this so I could have success.
  • Commented on 03-04-2011 at 8:22 AM
    Glad to help.
  • John #
    Commented on 08-31-2011 at 10:45 PM

    Thanks for the post, worked nicely. I knew what the problem was but couldn't come up with a solution. You are a life saver!