Is it possible to do a cross-site call, in Javascript, to a WCF service?
I don't mind if it's a POST or a GET.
But I've heard that these days, browsers don't allow cross-site calls with either POST or GET.
How can I circumvent this and still call a WCF Service?
There's not a whole lot you can do to circumvent the browser's cross-site scripting blockers. Those blockers stop XMLHTTPRequest's from happening to any domain but the one that loaded the containing script or page.
That said, there is one commonly used workaround: Use JavaScript to write a new entry into the DOM that references a src that is a cross-site URL. You'll pass all your RPC method arguments to this "script" which will return some JavaScript that will be executed, telling you success or failure.
There's no way to do a POST in this manner, the src URL must be a GET, so you can pass arguments that way. I'm not sure if WCF has a "GET only" method of access. And, since the browser will expect the result of the remote tag to be a valid JavaScript object, you'll have to make sure that your WCF service obeys that as well, otherwise you'll get JavaScript errors.
Another common method of circumventing cross-site scripting is to write a proxy for your requests. In other words, if you want to access domain test.com from scripts hosted on example.com, then make some URL on example.com that proxies the request over to test.com in the proper way.
For your example, the proxying is likely the right answer, assuming that WCF doesn't have it's own cross-site scripting restrictions.
Are you using jQuery by any chance? jQuery supports Cross-Domain JSON requests using "JSONP". You will be limited to GET requests, but I've tried it out and it works well! It's also very simple to get working.
See the "Cross-Domain getJSON (using JSONP) " section on this page for details:
http://docs.jquery.com/Release:jQuery_1.2/Ajax
And here's some background on JSONP:
http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/
Let me know how it goes!
New W3C recommendations are being standardised to allow cross-site requests between trusted parties via the Access Control for Cross-Site Requests specification.
This requires a server serving suitable Access Control HTTP headers and a browser capable of understanding and acting upon such headers.
In short, if a remote host says it likes your domain, and a browser understands what this means, you can perform xmlHttpRequests against that host regardless of the same origin policy.
Currently very few browsers support this functionality. IE8 apparently does (I haven't tested it) and Firefox 3.1 does (I have tested this extensively). I expect other browsers to follow suit quite quickly.
You shouldn't expect sufficient adoption of compatible browsers until 2012 at the earliest.
That's the ultimate solution to the problem. The downside is waiting a few years before it can be used in mainstream applications.
If this is for use within an environment you fully control, such as for an intranet where you can determine which browser is used and where you can configure multiple servers to issue the correct headers, it works perfectly.
To expand on Ben's answer... I extended our WCF service to support JSONP calls from jQuery using code similar to this example from Microsoft:
http://msdn.microsoft.com/en-us/library/cc716898.aspx
Related
I'm struggling at the moment with the idea of creating a cross-origin request proxy or not.
I have a jQuery application that interacts with an API, making at least 4 requests to that server on the initial page load. Both servers are completely under my control, but they are on different subdomains. For that reason, I've been heading toward the approach of using JSONP to get around the cross-origin request policies.
However, I'm really missing out on one feature in particular: getting HTTP status codes for the requests. The way JSONP + jQuery work, the request works or it doesn't. If it doesn't, I specify a timeout for the request and if that timeout is reached I assume a failure (there's no way to know otherwise). I'd really like to be able to respond to a 404 vs a 500 error from the API server.
This led me to thinking a local proxy may work better - but it would then tie up server-side resources (server that holds the jQuery application + Sinatra application) instead of client resources (the browser). That can certainly add up when each page load is 4+ requests to the API server, even though it wouldn't block the application from loading.
I understand this is not a true "question" - so feel free to flag this / close it if inappropriate. However, I'd really like to get some opinions on the subject. I'm introducing some complexity by developing a local proxy in Ruby.
I'd stick to JSONP and the direct communication between the subdomains.
Also, you might want to check out (hacky) methods of using iframes for communication. Iframes are not subject to the inter-subdomain restriction. They can communicate as long as both subdomains belong to the same top domain.
JSONP has some limitations and is not your only option. Since you control both domains have you considered using CORS? If not, check it out: http://www.html5rocks.com/en/tutorials/cors/
You can read about JSON-P vs. CORS here: http://json-p.org/
I am learning about he Prototype Ajax API. I was reading their documentation and I saw this:
Remember that for security reasons (that is preventing cross-site
scripting attacks) Ajax requests can only be made to URLs of the same
protocol, host and port of the page containing the Ajax request. Some
browsers might allow arbitrary URLs, but you shouldn't rely on support
for this.
So does this mean that I can't make requests to a backend of one app from another of my apps? Or am I just misunderstanding this. I would really appreciate some clarification for a new javascript learner, like me. Thanks
This is the same domain origin policy. This is enforced by web browsers, for security reasons.
In short, without this restrictions, ajax requests would allow you to retrieve any web page on the behalf of the user. This would allow you to read his emails if he was logged-in on his webmail.
Take a look at JSONP, for doing cross-domain ajax requests. (Notice the P in JSONP.)
This seems to be adding JSONP support to Prototype: http://dandean.com/jsonp-for-prototypejs/
I need to find a way to notify a 3rd party website about an user action on my website. A server sided connection is not desired. Hashing with private keys is used to sign the request so users can't abuse it.
My question is how I can send this request safely.
tracking image: XSA possible
iframe: XSA, frame breaker
script include: evilness at its best
JSONP (with jQuery): ??
others?
Does someone know if it's possible to inject Javascript in JSONP answers? I mean to bypass browser boundaries JSONP is Javascript that calls a function with the JSON as parameter but it could also contain other javascript calls. Does jQuery somehow check if there is malicious content in jsonp callbacks?
If you only need to target modern browsers, and you control all the domains, you can create an HTTP access control policy to allow them to communicate with each other. However, since that doesn't appear to be the case, you're going to be stuck with JSONP.
It's funny that you mention "script include" as "evilness at its best", because that's exactly what JSONP is. Since, until recently, browsers were incapable of cross-domain requests, the only way to get anything from a 3rd-party client-side was to include a script from that 3rd party. JSONP simply takes advantage of this workaround returning the JSON inside of a function definition, which your script can then call to get the included data.
When using an XMLHTTPRequest in javascript, I want to send it to an external website, rather than the one where the .js file is hosted. To send it to test.php on the current server, I would use
request.open("POST", "test.php", true);
but for the second arguemnt, how do I send it to another website. "example.com/test.php" looks for a file on the current server, and "http://example.com/test.php" justseems to outright fail.
You can't for security reasons. See the same origin policy for JavaScript.
There are some workarounds that exploit browser bugs or corner cases, but using them is not recommended.
The best approach is having a server-side proxy that receives Ajax requests, and in turn, sends HTTP requests to other servers. This should be carefully implemented by sanitizing input and whitelisting the types of requests that are sent, and the servers that are contacted.
This sounds like a bad case of Same Origin Policy, my friend :)
You can't (for the most part) use XmlHttpRequest to get data from an external website. What you can do, however, is dynamically create a SCRIPT tag and reference an external address. jQuery wraps this functionally as part of its ajax handling.
Indeed you can. Not in any browser although.
In Internet Explorer 8.0 there is XDomainRequest, an object enabling cross-domain requests. You would need to properly handle request made with this object on server by sending Access-Control-Allow-Origin header first with "*" or requester domain name.
Since you are doing some hacky things anyway, why not trying to use it on IE8 first?
If you have control over the server, you can use this header in the HTTP reply, although it may not work with all browsers.
Access-Control-Allow-Origin: *
my js file calls uses an xmlHttpRequest to display an rss feed. when i reference the java script within my html page, my browser renders an error: Permission denied. and therefore, my script is being blocked. i am not allowed to change the security settings and would i'd appreciate any work around tips. thanks!
It's called the same origin policy. There's no easy workaround.
Simply put, XmlHttpRequest doesn't allow you to perform ajax calls across domains. Meaning, if you're website is mydomain.com, you can't use XHR to call out to pages (xml or otherwise) on someonelsesdomain.com.
There are work-arounds, typically using flash (less elegant) or webservice proxies (more elegant). Google "cross domain ajax calls" for more help.
Cross-origins call? You can't do that ( at least not directly e.g. need an extension/plugin etc.).
You need a proxy server... a utility that will allow access to foreign (in this case, on another server) material on your own server. Since (as the others mentioned) Browsers have security features enabled to prevent you from accessing content via AJAX on these foreign servers, a proxy will enable you access to this content locally.
this .net method was perfect and easy to implement: http://www.asp101.com/articles/john/megatokyo/dotnet.asp