I'd like to get some clarification on what cross-domain AJAX means in terms of the mechanics behind it.
Say for example, I have a website http://www.example.com. This website contains a javascript file, which within contains several standard jQuery based AJAX calls (e.g. $.post(), $.get() etc), located at http://www.example.com/js/script.js.
Now, I have another website http://www.helloworld.com, which contains the following;
<script type="text/javascript" src="http://www.example.com/js/script.js"></script>
Would the AJAX requests within http://www.example.com/js/script.js which make requests to http://www.example.com be considered "cross-domain" and therefore carry compatibility issues when the file is included on http://www.internet.com?
Any answers would be great!
JS is executed on the client side, so it doesn't matter where the source of the file resides, it'll be executed from the domain in the address bar.
In order to be able to include a javascript from another domain, the sever that serves that JS need to provide the file with the correct headers.
In particular the headers need to have the Access-Control-Allow-Origin set for the domain requiring a cross-domain JS.
Just for test purpose you might want to run Chrome with the parameter --allow-file-access-from-files and it won't stop cross origin requests.
Related
So a couple of days ago i was looking for something like this and had actually found it but never found a use for it. I know its listed somewhere on mozilla's site but i forget what the function is called.
In anycase i wish to request an external domain that doesn't have cors and does not requir external help from things like proxy's. its a rather recent function added to javascript as when i read about it (before i forgot the name) it was listed as expiremental technology. It's supposedly a safe alternative to CORS the only catch is unlike cors you are not allowed to view the response.
What i want to use it for is to basically see if the status code returned is 404 or 200 so i can tell users whether a specific site is having issues and since the ammount of sites that would be requested is huge if i do it server side id prefer to have it done in a clients browser only on specific pages.
I think you could get by with sending a HEAD HTTP request.
Ok, here's the problem:
The remote site needs to pull complex html page content from other domain. Iframe solution is not good enough because of the problem with determining the page height, and cross domain ajax is not allowed on IE browsers. There is JSONP but amount of code that needs to be served is too complex and we also need to serve some funcionalities.
The solution:
On server side we are dinamically generating javascript that contains all the complex html content in a string variable. On remote side we just include call to this script and we put a on the page. Div is then filled with content from served variable. It works cross domain on ALL browsers and the content displays perfectly :)).
The question:
What's wrong with this approach? Why there is no mention of such solution anywhere online? It seems perfect for serving any kind of widgets and alike content, and now I'm affraid there is some big fallacy in it:)?
Please debunk it :)
There is no problem with this approach. Cross domain is forbidden on client side for security matters, but on server side you do as you wish.
The difference here is that you have to reload a page in order for it to query the other domain and then push it to your page. So basically you could do the following :
1- Your javascript does an ajax request to it's own domain.
2- On the server side, you make a cross domain request
3- You print some js/html to be used by the requester
In that scenario, you have one more request than doing it directly on the client side.
As Pointy commented, this is essentially the same as JSONP. Keep in mind that most browsers block sending cookies to the 3rd party site though.
Cross domain is possible as long as the server sends an access-control-allow-origin response header. See the linked article for an example
http://www.leggetter.co.uk/2010/03/12/making-cross-domain-javascript-requests-using-xmlhttprequest-or-xdomainrequest.html
I'm currently working on a web application that customers can add to their webpages by adding a javascript link to a js file on my server. The application read all the javascriptfiles from my sever, but I still get an error when trying to use ajax to get data from my database. I didn't think that would be a problem because the files is on my server.
Can I fix this or do I have to make a cross-browser solution? I don't have any control over the costumers server.
Thanks in advance
Mikael
This is not possible: When you execute a remote script, it runs in the context of the containing document.
There are some popular workarounds for this:
Using an iframe, which fixes the cross-domain problem but doesn't integrate well with the remote site (e.g. no custom styling)
Using JSONP to make cross-domain Ajax requests (detailed explanation here)
Using a server-side proxy script (not an option in this scenario)
Using YQL (I'm not familiar with this but it's said to work)
The same origin policy is based on the host document not the script itself.
You need to use a cross domain ajax technique.
if in the website http://www.mysite.com there's an external js file added as
<script src="http://www.yoursite.com/new.js"></script>
within the http://www.yoursite.com/new.js js file, there's an ajax call to a script in http://www.yoursite.com/new.js
in such a case will there be the same-origin policy security problem, as it's calling a script in a site from another website?
There will be a problem. new.js run in the scope of mysite.com, not yoursite.com.
EDIT: a more detailed explanation would be: when mysite.com is openning a tag, that script runs in the scope of the current page. The source of the script does not matter: it can be inline, local source, or remote source, it is still considered part of mysite.
As you know, scripts in mysite.com cannot access anything on yoursite.com due to the same origin policy. So you cannot do this.
As an advanced option for cross-origin communication look at jsonp. It will require yoursite.com to provide a special handling, but if you have control on both sites then this should not be a problem.
JSONP is precisely what you're looking for: http://en.wikipedia.org/wiki/JSON
The 5,000m overview is that JSONP uses the same mechanism for requesting external scripts as you're using above. The difference is that your server will recognise this and will package up the JSON response as the argument to a callback method. When your site receives this 'script', it executes it thereby returning the data directly into your callback method.
If you are able to use a framework like jQuery, most of the client side would be transparently handled for you. Check it out here: http://api.jquery.com/jQuery.getJSON/
I need to use AJAX to get the content of another page located on a different server from the one the AJAX is loaded from. The AJAX needs to send a POST request then return the result. how can i do this?
Set up proxy on your own server. Have your server call theirs and return the result.
if you control both servers, you can use one of the HTTP header fields for cross-origin resource sharing:
http://www.petefreitag.com/item/703.cfm
https://developer.mozilla.org/En/HTTP_access_control
There is no way to go around that policy. This policy is there for very good reasons.
That is also no problem as long as you're in control over the web application. You could simply redirect the call to the other server from your webserver and pass the result. This would work out like a proxy.
If you want to do that on the client and cross browser, you need some cooperation from the other server.
Either by:
1) using JSONP (inject a script tag with a callback function)
Only GET calls are possible though.
Security is an issue as the script has access to all resources in that page(data, cookies, ...).Here's a post that explain how to sandbox them and keep the data in your page safe.
2) POST looks possible using Kris Zip's window.name technique
If the cooperation from the other server is impossible, the server proxy as described in other answers is, to my knowledge, the only option left.