I have a website say xyz.com. i want to make an ajax call from say(http://pqr.xyz.com) to https://abc.xyz.com. but the call is failing to execute due to cross domain problem. Is there any method to overcome this. How xan i access the page via https.
If you want to make cross domain calls, you need to use JSONP.
This means you can change the server code so that the headers shows this cross-domain call is authorized. Depending on your server language, you'll have to do something like this :
w.Header().Set("Access-Control-Allow-Origin", "*")
w.Header().Set("Access-Control-Request-Method", "GET")
w.Header().Set("content-type", "application/x-javascript") // this one of course for json calls
Using JSONP instead of JSON will also mean that you'll enclose you JSON in a function call, for example
acceptServerAnswer({'thisis':'myjson'])
Use a server-side proxy or JSON
http://devlog.info/2010/03/10/cross-domain-ajax
Related
I'm loading my script on a domain and sending some data with POST and the use of Ext.Ajax.request() to that same domain.
Somehow the dev-tools show me, that there is a failed OPTIONS request.
Request URL : myurl-internal.com:8090/some/rest/api.php
Request Headers
Access-Control-Request-Headers : origin, x-requested-with, content-type
Access-Control-Request-Method : POST
Origin : http://myurl-internal.com:8090
It's both HTTP and not HTTPS. Same port, same host ... I don't know why it's doing this.
The server can't handle such stuff and so the request fails and the whole system stops working.
It's not really specific to Ext JS -- see these related threads across other frameworks. It's the server properly enforcing the CORS standard:
for HTTP request methods that can cause side-effects on user data (in
particular, for HTTP methods other than GET, or for POST usage with
certain MIME types), the specification mandates that browsers
“preflight” the request, soliciting supported methods from the server
with an HTTP OPTIONS request header, and then, upon “approval” from
the server, sending the actual request with the actual HTTP request
method.
If you're going to use CORS, you need to be able to either properly handle or ignore these requests on the server. Ext JS itself doesn't care about the OPTIONS requests -- you'll receive the responses as expected, but unless you do something with them they'll just be ignored (assuming the server actually allows whatever you're trying to do).
If you are NOT intending to use CORS (which sounds like you aren't purposefully going cross-domain) then you need to figure out why the server thinks the originating domain is different (I'm not sure about that). You could also bypass CORS altogether by using JsonP (via Ext's JsonP proxy).
Use relative url instead of absolute, then you will get expected result.
use before request
Ext.Ajax.useDefaultXhrHeader = false
Browsers don't allow cross-site AJAX calls (it's a security restriction).
Is there any possible solution ?
EDIT
I control only the caller website
If you control both parties then there a lot of options. Such as JSONP, or modifying header responses of the remote website. Unfortunately, JSONP only works if the remote website supports it. You can't force a JSONP call to a website that doesn't already support it.
However, as you have said, you only control the source website. You cannot hack the browser around this restriction for obvious reasons. You do have a third option which is creating a back-end proxy. You can use Apache and mod_rewrite to create a proxy. Here is on how to do this or this link which is more detailed.
For example
ProxyPass /api/gtalkbots http://gtalkbots.com/reverse-proxy-data.php
ProxyPassReverse /api/gtalkbots http://gtalkbots.com/reverse-proxy-data.php
Creates a proxy at /api/gtalkbots which will returns the repose from gtalkbots.com
Your best solution is to use JSONP calls.
function jsonp(url, params, callback){
var script = document.createElement("script");
script.setAttribute("src", url+'?'+params+'&callback='+callback);
script.setAttribute("type","text/javascript");
document.body.appendChild(script);
}
function doit(data){
alert(data);
}
jsonp('http://domain.com', 'foo=bar', 'doit');
In the opposite side, the website you're contacting must be able to return a JSONP formatted response in order for this to work.
There are 2 ways to do this, depending on whether the callee will ship out JSONP or not:
1. If you can, use JSONP
JSONP is a way to bypass the cross domain policy by returning a function call, rather than a naked JSON object. The P stands for padding, essentially just the part that calls the function.
For this to work, the callee needs to return JSONP.
Regular JSON looks like this:
{a: 12, b: 15}
JSONP looks like this:
callback({a: 12, b: 15});
When the AJAX request completes, the callback function (which you define in your own code) will be executed and the JSON data passed to it as an object, thus bypassing the cross domain policy.
2. If JSONP is not supported, mirror the request through your own server
The second option is to pipe data through your own server. Your JavaScript makes a request from your server, and the server then mirrors that request to the remote server and pings back the result.
Since the AJAX request is now made to your own server you won't run afoul of the cross domain policy.
There are two downsides to this approach:
Two requests are now required which will slow the response time a little, though probably not much as server to server communication will probably be via a fat pipe.
Since all requests now originate from your server you may have problems with IP based rate limits. This is the case with Twitter API calls. You may be able to mitigate against this by caching results.
will any webserver [IIS possibly] know whether a request is an AJAX request or a Normal one.
If you are using native XmlHttpRequests then there is no difference between this request and once generated by visiting a page or submitting a form. If you use jQuery to create the AJAX request then is adds a request header X-Requested-With: XMLHttpRequest. This header could be used to distinguish AJAX and non-AJAX requests.
Some (most?) frameworks can send a custom header, but, really, an ajax request is just the same as a "normal" request from the point of view of the server.
If you use curl, wget, telnet, or a program you write yourself, then the web server handles the request the same way - at the end of the day, it's all HTTP.
The easiest way for the receiving page to 'know' would be to send a query string parameter. This isn't 100% safe though.
Firebug can show you what is being sent to the server from both types of requests, try it out.
Possibly, it is not the webserver that can distinguish, but the server side code might be able to distinguish. If you are talking about ASP.NET and AJAX, then ScriptManager.IsInAsyncPostBack can be used to find whether a postback is from AJAX or not.
I want to use mootools and SqueezBox class to handle a request to a RESTful service. I don't want to use any server-side script. I am using AJAX. I send a request to the following url using GET method.
http://www.idevcenter.com/api/v1/links/links-upcoming.json
but I receive a 404 error. Is it because cross-site scripting? here is my code:
SqueezeBox.initialize({handler:'url',ajaxOptions:{method:'GET'}});
$('a.modal').addEvent('click',function(e){
new Event(e).stop();
SqueezeBox.fromElement($('a.modal'));
});
In Firebug console, sometimes 'aborted' is shown and sometimes '404'.what is wrong with that?
XMLHttpRequest is subject to the Same Origin Policy; if the document your JavaScript is running within is not from the same origin as the service you're trying to call, the call will be disallowed for security reasons.
There is now a proposed standard for cross-origin resource sharing to address this. It may be that the service you're trying to use supports it; if so, using a browser that implements CORS (recent versions of Firefox and Chrome do, as do some others) may work. IE8 supports it but requires that you do extra work.
You cannot use XMLHttpRequest (that is, ordinary "ajax") to call a service on a server that is not in your domain.
You can, however, use the JSONP trick, which takes advantage of the fact that the browser will load Javascript from other domains. However, the service has to know that you're going to do that, and it has to understand the protocol. That particular service seems perfectly willing to give me a JSON response, but it doesn't pay attention when I give it a "callback" parameter. (I've tried both "callback" and "jsonp" and the JSON blob that comes back is the same, without a function call wrapper.)
I would like to make an ajax call to a different server (same domain and box, just a different port.)
e.g.
My page is
http://localhost/index.html
I would like to make a ajax get request to:
http://localhost:7076/?word=foo
I am getting this error:
Access to restricted URI denied (NS_ERROR_DOM_BAD_URI)
I know that you can not make an ajax request to a different domain, but it seem this also included different ports? are there any workarounds?
Have a certain page on your port 80 server proxy requests to the other port. For example:
http://localhost/proxy?port=7076&url=%2f%3fword%3dfoo
Note the url encoding on the last query string argument value.
You could use JSONP. This is where you specify a callback with the request, the response from your ajax request gets wrapped with the callback function name. Rather than using XmlHttpRequest you insert a tag into the HTML document with the URL. Then when the response is retrieved the callback function is called, passing the data as a parameter.
Check this blog post out for an example
This is a browser restriction. All javascript calls must be to the same server and port of the home of the script. This will require something server-side to get around. I.E. have the process at localhost forward the request to localhost:7076.
It sucks, but it's necessary... Basically what you're going to need to do is proxy your AJAX request through a local proxy - some server side script / page / whatever on the same domain you're on - receive the call and forward it on to the other resource server-side. There might be some IFRAME tricks you could do but I don't think they work very well...could be wrong though, been awhile.