tags:

views:

347

answers:

1

I read a post about making JSON calls (with jQuery) safer by adding a dataFilter to parse the returned string.

However in the post it's explained (more specifically in a previous post linked from the above post):

It’s important to note the removal of the dataType parameter in the $.ajax() code above. This is required in order to prevent a double-eval of service responses containing only a single string.

Internally, jQuery uses a combination of the dataType parameter and the implicit type the response. If the dataType is "json" and typeof(response) is “string”, then jQuery uses eval() to deserialize the response.

But since I'm making a cross-domain call I can't remove the dataType it has to be set to json[p] to allow the call at all. But with this set the dataFilter isn't called, is there any way to filter the data without editing the internals of jQuery?

Anything important I've missed, just ask.

Thanks, Chris M

+1  A: 

The jsonp implementation accomplishes it's cross-domain magic by injecting a SCRIPT tag into the head of the document. There isn't any point where you can put in a filter to parse that response before it is evaluated.

great_llama
So just to clarify you're saying I can't stop jQuery eval'ing the returned response without editing jQuery directly?
Not even with modifying jQuery directly. The only way to get past the cross-domain security issue is by creating that script element, which gets parsed just like any other JS include.
great_llama
I think I understand now. A script tag is injected into the head with it's source set to the cross domain url with all url parameters etc. The browser automatically tries to load the contents from the source in the script tag, which just causes what ever service to be invoked. The services return value is then simply loaded like any other script by the browser, thus it's impossible to 'clean' the returning data.That correct?
Yep, jQuery just hooks itself into the onload and onreadystatechange events of that new script tag. It relies on the server that responds to the jsonp request to prefix with the callback name and wrap in parentheses. But as noted by the guy who proposed this all, you're leaving yourself open to a malicious response by that server.
great_llama
Was having a little trouble getting my head round it all and your responses where a great help, thanks!