Coldfusion CFCs, Ajax & the dreaded Parsing Error: The value returned could not be evaluated.

I have a bit of code I was working on today. Basically it’s a CFC function that creates an access code for a partner website

 <cffunction name="manageAccessRequest" returntype="string"  access="remote">
    <cfargument name="partnermasterid" required ="true">
    <cfargument name="type" required ="true">
    <cfset var manageAccessRequests = "">
    <cftry>
    <cfquery name="manageAccessRequests" datasource="dsn">
        update partner_master set approved = <cfqueryparam cfsqltype="cf_sql_integer" value="#arguments.type#">,
         dateapproved = <cfqueryparam cfsqltype="cf_sql_timestamp" value="#now()#">
        where partnermasterid = <cfqueryparam cfsqltype="cf_sql_integer" value="#arguments.partnermasterid#">
    </cfquery>
    <cfif arguments.type eq "9">    
        <cfset result="AccessRejected">
    <cfelse>
        <cfinvoke method="sendApprovalNotice">
            <cfinvokeargument name="partnermasterid" value="#arguments.partnermasterid#">
        </cfinvoke>
            <cfset result="AccessGranted">
    </cfif>
<cfcatch type="any">
    <cfset result = "#cfcatch.type# - #cfcatch.message# - #cfcatch.detail#">
</cfcatch>
</cftry>
<cfreturn result>
</cffunction>

The sendApprovalNotice function is a local call. Basically, it does a query or the partner table and formats a cfmail to send the access code. Pretty simple stuff.

<cffunction name=”sendApprovalNotice” >

You’ll note that manageAccessRequest is returning a string – either AccessRejected or AccessGranted to use in a simple alert box on the calling page

function manageReq_response(obj)
{
    alert(obj)
}

Again nothing complex here. Except it wasn’t working. Whenever I submitted a  cfargument type of 9 which is DENY, I got my AccessRejected alert box. However, when I submitted a value of 1  APPROVED, the browser popped up with the dreaded generic ajax Parsing Error: The value returned could not be evaluated. (note: this is a “friendly” error thrown by JSMX but the following should apply to all ajax parsing errors) This showed me the manageAccessRequest was working correctly and whatever was failing was happening in the sendApprovalNotice function

Hmmm. Open up Firebug,and what do I see

<br> <wddxPacket version='1.0'><header/><data><string>AccessGranted</string></data></wddxPacket>

Look like a normal wddx return packet – stare, stare, hmmm hey what’s that <br> doing there. That can’t be there.

Looking at the code for sendApprovalNotice I find it just before my cfsavecontent section where I create the HTML to go in the mail.

<cfset theaddy = AccessByID.contactEmail>
</cfif><br>
<cfsavecontent variable=”vTmp”>

Remove the <br> and all works fine.

Now WHY? Well, the returned value from an ajax call to a CFC can not contain any characters outside of the wddxpacket and the <br> was causing the parsing to bork. This one was pretty simple to find. I remember struggling with this issue a couple of years ago with a very large CFC function and the culprit was a . (dot) at the end of one line. It was almost invisible to my frustrated eyes, especially in the days before Firebug.

Now, back then, as now, I’d forgotten the simple way to prevent this kind of typo related hi-jinx. Use the output=”false” attribute

<cffunction name=”sendApprovalNotice” output=”false”>

This forces CF to ignore all text outside of a CF tag. Frankly, you should never have display code in a CFC in any case. Remember, my correct “display code” is inside a cfsavecontent and is therefore not being displayed by the CFC.

The other benefit to using output=”false” is that it can help reduce whitespace.

So moral of the story. If you see Parsing Error: The value returned could not be evaluated on a callback from a CFC, check for stray characters (just to keep your code clean) and add the output=”false” attribute

A picture is worth a thousand malcious websites

I’ve had quite a few views of my quick post on generating a QR code. QR codes DO have a down side as highlighted in this post from the Internet Storm Center.

These [qr] codes can link directly to browser exploits, or could include other malicious content to manipulate your phone.

As I just confirmed by scanning the code on the ISC page, one of the most popular QR Code apps for the iPhone, Scanlife  does NOT “tell you what URL they are going to open up before they actually load it.” The app immediately loads the page, which is a fairly large security risk. As far as I can tell the app (v3.12 at time of writing) provides no optional setting to view or stop the page from loading once scanned.

Moral of the story, random scanning of QR codes can be quite dangerous so watch yourself.