I've just read this article over at Particle Tree
Is this accurate:
If security is not an issue, a JavaScript based API will actually work out very nicely. If we host a JavaScript file, users of our API can include this file on their page, and call functions from that file. Cross Domain Ajax isn’t a problem since the file sits on our server.
I was always under the impression that would fail when attempting an ajax operation. In fact I'm sure I've written some code to try this, can anyone verify if this is accurate?
In fact I'm sure I've written some code to try this, can anyone verify if this is accurate?
As written, it isn't. The origin of the JS doesn't matter, only the origin of the page and the origin of the data you are trying to access.
I think it is trying (badly) to explain JSONP which would allow you to bypass the same origin policy (since the script and the data are the same thing in JSONP).
You can do cross domain, but you have to set the call up correctly. jQuery, as always, makes it easy. You can set a crossDomain flag in the ajax call.
Please reference: jQuery Ajax Call Documentation
Related
JSONP is said to "by-pass" the same origin policy. I take this to mean that using it allows the script to load from a remote server on a different domain and run locally on a website.
I'm not clear however on what exactly can be done by the script while it is running.
Is it just as privileged at JavaScript loaded from the same domain? Are there any additional restrictions imposed on JSONP that one can count on?
In a browser, <script> tags may reference scripts located in any domain. Script resources are not subject to the same-origin restrictions that an Ajax request is.
As such, you can dynamically insert a script tag that will refer to a script on any domain and it will load successfully and not be blocked by same origin restrictions.
This is how JSONP works - by making a cross origin request by requesting a remote script to load and run. It is not a blanket bypass of the same origin restrictions because you cannot just directly make a remote API call using JSONP as the server you are contacting must explicitly support JSONP because it's a completely different type of response. So, in essence, the server you are contacting must explicitly support and allow this cross origin request via JSONP.
I'm not clear however on what exactly can be done by the script while
it is running.
Once you request a JSONP script, that script is just a piece of Javascript running in your page. It can literally do anything that any script running in your page can do.
Is it just as privileged at JavaScript loaded from the same domain?
Are there any additional restrictions imposed on JSONP that one can
count on?
It's just a script running in your page. It can do anything that any script running in your page can do. By convention, it is supposed to call a callback function that was specified in the URL and pass it some data (the result of the request), but it could do any other thing that Javascript in your page can do.
There are no additional restrictions on JSONP scripts. The browser doesn't know if a script is JSONP script or not. It's just a script that can do exactly the same things as any other script.
JSONP is basically a hack that solved a problem before browsers supported CORS. I can't think of any reason these days to design a solution based on JSONP any more if you can use CORS. CORS is more secure as it doesn't let some other site run random Javascript in the context of your page.
JSONP works by employing ordinary <script> tags and content fetched as JavaScript via an HTTP GET. The browser basically thinks it's just fetching another script for use by the page, so the code with which the third-party site responds can do anything it wants to.
"Well-behaved" JSONP sources send back, by convention, a call to the function whose name you give as the "callback" parameter in the URL. That is, the server responds with a JavaScript statement:
yourCallback({ name: value, ... });
There's really no way for your code on the page to tell whether that's really all that happened, however.
I'm new to AJAX and I have what I think is a simple question. I know you can create a page that will respond to an AJAX call. Is it possible to just get any page with an AJAX call?
So I mean to say, can I do anything with an AJAX call that I could do with a URL?
EDIT #1
Thanks for all the responses! Really helped clarify!
Yes and no.
AJAX is a powerful mechanism by which you can retrieve and/or load data into the DOM in a flexible manner. You can do things like grab the content of another page and display all or portions of it on your page. There is a catch however.
Due to security reasons, you cannot depend on being able to make an AJAX call in a cross-domain manner unless the server on the other domain is properly configured. This is known as Cross-Origin Resource Sharing (CORS). You can read more about that here - http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
Alternatively, some servers will expose API's that work with JSONP (JSON with Padding), which is a sort of workaround for the Same Origin Policy (SOP) that normally prevents cross-domain requests of this nature. In JSONP, the remote endpoint in essence wraps the response in a javascript function. You can read more about JSONP here - http://en.wikipedia.org/wiki/JSONP
You are limited to requests within the same domain, unlike a normal URL. There are ways around it using CORS or JSONP in that case.
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
No.
One example is that you can't use AJAX to upload or download files. One workaround for this is to target the upload or download to a hidden iframe and poll that frame for a response. Update: it seems some support for this is part of HTML 5 (see https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications).
A second example is navigating the user to another page. You can load a second page and replace the contents of the window with it, but the URL will still be the original page (the "refresh" and "back" features of the browser will behave accordingly).
A third is cross-domain requests. AJAX calls are limited to the domain the page originated from.
Is it possible to do AJAX calls from inside an iframe that has a different domain source?
I've tried script injection but it doesn't work because the iframe's source is secure.
I made a simple fiddle with California DMV website here.
I'm getting DOM exception 8 error. Is it a security issue?
It is not possible to modify or make JS calls in an iframe with a different domain source. This is restricted in all browsers for security reasons.
See the "Same Origin Policy" for a description of how inter frame security works. In a nutshell, there is very little communication allowed between frames on a different domain for security reasons. You cannot make any direct Javascript calls between frames on different domains.
There is a way to make cross domain ajax calls and it involves using JSONP. Basically, you inject a script tag into your own frame and that script tag points to server endpoint anywhere on the web. Since the src value of a script tag is not restricted by the same origin policy, you can reach that server. But, now you need to have a way to get that result back. That is done using JSONP where you specify in your server request a javascript function that you want the returned javascript to call. That returned javascript can have javascript data in it that is then passed to the desired function. JSONP requires cooperation between both client code and the server code since a normal ajax call might not support the extra part of JSONP. But, with this cooperation of both sides, you can get around the same origin policy for server endpoints that support JSONP.
HTML5 has a new messaging system that can safely communicate data (not direct JS calls) between cooperating frames in different domains. See here and here for a description of how the HTML5 messaging works.
Yes it's a security issue because of the Same Origin Policy enforced by most browsers: http://en.wikipedia.org/wiki/Same_origin_policy .
You can look into JSONP http://niryariv.wordpress.com/2009/05/05/jsonp-quickly/ which is specifically designed to get around this.
Is it possible (and if so, what's the most secure way) to read a JSON file from a subdomain such as somesubomain.maindomain.com in a JS script residing in maindomain.com, another.maindomain.com etc?
Thanks!
Have a look at how document.domain works: https://developer.mozilla.org/en/DOM/document.domain
Another solution would be make your json file a JavaScript file (jsonp-style) which calls a function so it can be embedded using a script tag which does not have same-origin restrictions.
Your not supposed to due to the same origin policy enforced on all browsers, but you can... Check out this explanation of cross domain ajax requests.
http://alexsexton.com/?p=154
JSONP is what I found to be the easiest to work with for this type of stuff.
I do this two ways:
Have your server make the call on behalf of your client. What I mean by that, is take the call you were going to make from the browser, and make it a web service on the server. Then have your client call your webservice, which will then make the call and return the response. This allows you to inspect what's being sent back and forth.
Use JSONP. Their server must be configured for this, and I'm not sure there is any added security..
When requesting (ht|x)ml with ajax you can only send requests to the same domain. But if you request JSON you can send it to any domain. Why?
I'm told it's for security but why would a website do something malicious via ajax rather than just directly if that makes sense.
Check out this wikipedia article.
The reason why JSON is 'safe' is because you have to pass it through a callback. The remote site will run return JSON and your javascript library will not just run it blindly but try to pass it to a function you specify, like jsonpCallback( response ). Since you aren't running the remote code directly much more is under your control and all is mostly well in the world.
The reason it's called JSONP has actually little to do with JSON itself. Doing a cross-domain ajax request is as simple as adding the <script src="http://url.com/data.js></script> tag to your HTML web page; this is the base concept of JSONP and cross-domain ajax.
What happens is that the data.js file is interpreted by JavaScript. This gives us the ability to get data from that data.js file (which is located on another domain), if for example it loads a function that is available in the current scope.
Here is an example of why someone would hack an AJAX request.
https://blog.codinghorror.com/preventing-csrf-and-xsrf-attacks/
http://directwebremoting.org/blog/joe/2007/04/04/how_to_protect_a_json_or_javascript_service.html
Injecting JSON directly in your page is not secure at all.
You offer to the loaded scripts full access to the resources in your page(data, cookies, logic).
If the injected code is malicious, it can run actions on your server, post back data to their server(POST is allowed cross domain, not the response but your data are sent anyway), etc...
We're building a web app that makes a heavy use of cross domain accesses.
To solve this problem, we came with a rather simple JSONP sandboxing solution.