Working with a new client can be exciting, challenging and sometimes will call into question your sanity for your chosen profession as a developer. Most often times this happens over the course of your career, rarely will it happen all within the same week. This was that kind of week for me. It all started out with a simple idea to use some JQuery and AJAX love on some old form and display pages in a client’s application to show some simple ways to freshen up the UI and consolidate code. This is also where the trouble began as well. Long story short I was making AJAX calls to some ColdFusion CFCs to return data to display information on a page.
$.ajax({
type:'get'
,url: '/com/some.cfc'
,data:{method:'someMethod', ReturnFormat:'json', passToken: someValue}
,dataType: 'json'
,success: function(){
my success logic here;
}
,error: function(){
my error logic here;
}
});
The AJAX call properly requested the format returned to be a JSON Object and looking at Fiddler confirmed this to be true.
{
"COLUMNS":["COLUMN1","COLUMN2","COLUMN3","COLUMN4"]
,"DATA":["VALUE1","VALUE2","VALUE3","VALUE4"]
}
On my local machine everything worked perfectly, as well as in the Testing and Staging environments. Production was a different story, the code failed. A quick inspection of Fiddler reveals the presence of a JavaScript cookie being injected into the response header coming back from the method of the ColdFusion CFC for the requested data.
<SCRIPT>
document.cookie = "IV_JCT=%2Fsomevalue";
</SCRIPT>
{
"COLUMNS":["COLUMN1","COLUMN2","COLUMN3","COLUMN4"]
,"DATA":["VALUE1","VALUE2","VALUE3","VALUE4"]
}
As we all know this is not good because any extra data appended to a JSON Object before or after the object renders the response useless to the AJAX call. Unbeknownst to myself, the client is using Tivoli in their single sign on implementation in the production environment. Quick glance over the Tivoli documentation let me know the client has implemented the use of Junction Cookies to maintain state of which client connections belong to which requests for each application. Documentation further goes on to say that the JavaScript cookie will be injected into all response headers with a document type of text/html.
Solution to the problem? Two lines of code added to the top of the CFC to change the response type to something other the the default text/html response.
<cfcomponent>
<cfset response = getPageContext().getResponse()/>
<cfset response.setContentType("application/json")/>
<cffunction name="getSome" access="remote" output="true" returntype="any">
<cfargument name="SomeValue"/>
my method logic here
<cfreturn rtnValue/>
</cffunction>
</cfcomponent>
Thanks to Ray Camden I was able to implement a solution to the problem by changing the document content type returned from the CFC method to “application/json” to have the Tivoli servers just pass the response back unmolested.
