TAG: jQuery

Reading JSON through JQuery from Cross Domain ASP.NET Web Service

Recently I had an issue with JQuery and accessing JSON from a cross domain ASP.NET Web Service. After much googling, I stumbled upon many articles that provided no fix that would solve the issue.

Every sample I found was some derivative of the following code:

Nearly every post pointing out that the contentType argument was the issue but it still didn’t work when I included it. There were posts that said you can’t use GET and had to use POST. There might be valid security issues with not using GET but that’s another topic of discussion. in the case of an open web service where you’re providing raw data to be consumed, a GET should suffice just fine.

To support GET, you need to add the following attribute tags to your asmx.cs:
[sourcecode language=”csharp”][WebMethod(), ScriptMethod(UseHttpGet = true, ResponseFormat = ResponseFormat.Json)][/sourcecode]

This will cause ASP.NET to automatically serialize the returned data to JSON without requiring you to do it manually in code. There are no issues when making the call locally either. The second you go cross domain, the call fails.

A few articles mention JSONP (JSON with Padding) which is supposed to provide a workaround for the Same Origin Policy in JavaScript. Once I implemented the JSONP, the entire function

 

jQuery fancybox ‘*.support not defined’ or ‘b.support not defined’ Error

I was importing some code from static HTML pages into a client’s home grown CMS system this morning. When I reviewed the site in Firefox with Firebug running, I was seeing the error:

b.support not defined

The site uses Fancybox to display the window overlays within the site so I had to step through the code and to find out what broke during the migration. Turns out it was a stupid mistake on my part.

Make sure that you include a reference to the jquery library before you load fancybox.

 

SSL, jQuery, and CDN

I just got whacked by a minor bug with SSL and the Google CDN (totally my fault, not theirs). I stuck the reference to the CDN in my master page not realizing one of the pages would be served up as secured by the vendor due to compliance issues. It made it through all testing because none of the staging/dev environments were configured for SSL and I was not made aware of the fact that we’d be serving the page up through SSL. Internet Explorer 8 prompted users about the insecure content before rendering the page. In their infinite wisdom, Microsoft decided to implement a new workflow for insecure content where the content is ignored and the page renders immediately with the unsecured content ignored. Since jQuery was used on multiple parts of the form, the site essentially broke. Google Chrome and Firefox seem to recognize the CDN as a trusted source and render the page as expected.

To fix the site, I added a javascript check to set the appropriate prefix to the CDN call:

 

There are no more results.