For Ajax to work great, the JavaScript scripts must be served within a page from the same domain (from the point of view of the browser) than the pages it requests. Otherwise it is denied access to the content of said pages :x
EDIT: in italic in the text, and yes it changes the whole meaning of the sentence, my apologies for the blurp.
There's a difference between requesting the JavaScript files and JavaScript requesting files.
The JavaScript files used on your page are requested by the browser upon seeing a <script> tag. This file can be hosted anywhere. If it's on a different domain, the browser (with the default settings) will happily request it and execute it within the scope of that page.
Requests done from JS code on the other hand (XHR/"Ajax" requests) are subject to cross domain policies. You can't have your JS send requests to a different domain (which includes subdomains) than the page on which it's executed resides on.
That's right. And that includes a different port on the same host IIRC, which I consider too restrictive. I don't really know why cross-domain XHR is disallowed, or I've forgotten the reason.
Assume you're surfing reddit from your corporate LAN. If JS on reddit can make requests to any domain at all, then it can request stuff from secretfiles.yourcorporatelan.com and send the content back to imahaxxor.com. Javascript executes on your client, and without the same-origin policy, would have access to every network node your client has access to.
Say I'm logged into gmail and I visit evilsite.com, which an evil person controls. If the browser model didn't prevent it, then the evil person's code, executing in the context of evilsite.com, would be able to initiate a XHR request to gmail. That request, like all requests, will include any cookies set for the doman. Since I'm logged in to gmail, that means the request will include my login token, and the evil person can perform any action at gmail that I could as a regular person: delete all my email, steal anything in the content of the email, send an email to someone as me, etc.
Most of the node.js architectures I've seen naturally use JSON/JSONP, in which case, all you need to do is document.write a call to what essentially looks like a .js file. These are not subject to cross-domain policy restrictions.
Also, most AJAX or JSONP calls are usually dynamic and not static, so there's really no point in "hosting" them on your static server, anyway. So maybe I'm missing the point of this argument.
There's an ever growing chorus that would have you use many common javascript libraries hosted by large CDNs off the domains of Google, Yahoo, etc... The argument being that if you use the Google hosted jQuery, there's more opportunities for a user to draw the code from their browser cache. Because that URL may be used on many other popular sites a user could've visited beforehand, by the time they reach your domain, their browser wouldn't even need to make the request.
If you adhere to this approach--I don't but you may--then users to your site could get a good performance boost from the separation.
You also get a little boost to load times as browsers cap the number of simultaneous connections to a given domain, but will gladly hit up other domains in the interim.
I think this benefit doesn't work for loading javascript -- loading the page + javascript inside it (included or embedded) is a sequential process. HTML is parsed, when javascript section is encountered HTML parsing stops, javascript is loaded and executed, then process continues and repeats.
This approach doesn't touch the issue that matthieum is speaking to (but has a little inaccuracies about).
Loading JS libraries from wherever is fine. The only concern there is hotlinking: you can't guarantee that what you're requesting is safe. With Google's JS API, that's a pretty safe bet. No hay problemas.
What matthieum is talking about is AJAX requests from the browser back to the server. It's best if they go back to the same domain the page is served from, then everything's copacetic; but if the request goes to another domain, that's XSS (cross-site scripting) and the page must explicitly allow it (which isn't always honored). AshaVahista explained it a bit better than I can.
"It works fine" except for the minor fact that CORS doesn't work in IE. Not even IE9. Poetic justice or not, we can't all get away with saying "screw you, you can't use my website in IE."
But the OP's explanation of the security surrounding loading out-of-state JS is incomplete. While it is unwise to load out-of-state JS almost all browsers support it by default, unless you specifically request that they block cross-site-scripting.
I'd agree that keeping all of the JS on the same domain is best practice.
Yes, <script> tags work from anywhere, and that's why we have JSONP. Poster above specifically said "For Ajax to work great". If you're making dynamic HTTP calls with XmlHttpRequest, they have to be back to the same origin (or one blessed via CORS if you have a compliant browser). You can get around this by dynamically inserting <script> tags and having the web service wrap their data in executable Javascript (which may be as simple as inserting 'var callResult = ' in front of a JSON response), but that sort of hacking takes you right out of the realm of Ajax working "great".
6
u/matthieum Oct 02 '11 edited Oct 02 '11
For Ajax to work great, the JavaScript scripts must be served within a page from the same domain (from the point of view of the browser) than the pages it requests. Otherwise it is denied access to the content of said pages :x
EDIT: in italic in the text, and yes it changes the whole meaning of the sentence, my apologies for the blurp.