supporting $.getJSON for JSON-P services in CSP environment

Reported by:	godmar@gmail.com	Owned by:
Priority:	low	Milestone:	None
Component:	ajax	Version:	1.8.0
Keywords:		Cc:	jaubourg
Blocked by:		Blocking:

Description

Google Chromium has recently started enforcing a CSP on core extension code that forbids <script> loading from anywhere but from whitelisted https:// sources. As a result, I need to sniff and use $.get or $.getJSON like so:

if (inCSPEnvironment that restricts <script> insertion) {
   $.get(url_nocallback, function (jsonText) { processJSON(JSON.parse(jsonText)) });
} else {
   $.getJSON(url_withcallback, processJSON);
}

It would be nice if I didn't have to, that is, if $.getJSON handled that for me so my $.getJSON code wouldn't break in a CSP environment in which <scripts> cannot be inserted (although cross-domain XHR is legal).

This is just an idea - a lot of frameworks/libraries are now being made compatible with CSP environments, so you'll probably be seeing increased use of jQuery there. But of course, you could also leave that to the user (good arguments can be made for that).

Attachments (0)

Change History (4)

Changed August 14, 2012 01:11AM UTC by dmethvin comment:1

component:	unfiled → ajax

Changed August 21, 2012 01:01AM UTC by dmethvin comment:2

cc:	→ jaubourg

It seems like being explicit about this in your code is a bigger win for code clarity. Why ask jQuery to measure a dozen different parameters about the environment and make a decision that is still sometimes wrong when you know what you want? You can wrap your $.ajax call in a function to keep your code DRY. That simple extra if in your code is going to end up being a much more complex thing inside jQuery because of the myriad conditions it may affect.

Julian, can you weigh in and give this an up/down?

Changed August 21, 2012 02:09AM UTC by godmar@gmail.com comment:3

FWIW, my wish would not only be for jQuery to "do the right thing" when I call $.getJSON(), I'd also like it to figure out if we're in a CSP environment. (Currently, I do 'typeof 'chrome' != 'undefined' && chrome.tabs != null' - as an example, which detects if my code is running in a CSP-restricted Google Chromium extension background page - but CSP's restriction on inline-scripts can - and will - appear elsewhere.)

jQuery is known for sniffing internally what features are and aren't available and to compensate for them/choose the one; the presence or absence of CSP restrictions could be viewed similarly.

The part I really don't like about my proposal is that it would require manipulating the URL to remove a 'callback=?' clause, which would entail some assumptions about the structure JSON-P URLs.

Perhaps this is better located in a plug-in.

Changed August 21, 2012 07:31AM UTC by jaubourg comment:4

priority:	undecided → low
resolution:	→ patchwelcome
status:	new → closed

Even if we could come up with a clean CSP feature detection, we would still need to be able to ask if a given url is white listed or not (I haven't checked but I seriously doubt we can) and then make huge assumption (in your case) regarding if we have to put a callback argument or not. Beside why would the service suddenly return JSON and not JSONP all by itself? You'd still need to pass a specific parameter to somehow ask it to (though proper use of an Accept header could do the trick).

Sounds like it's better for the actual application to deal with this kind of logic.

I tend to agree with you that a plugin is the right place a clean CSP feature detection and I'll close this as patchwelcome. I have nothing against detecting CSP and choose a transport accordingly (script tag vs xhr), I'd just need a clean way to do so which I don't think exists yet.

Side navigation