I run a site A and I want to be able to POST data to site B, which is hosted on a different subdomain. Now I have complete access to A, but cannot modify B at all.
My requirements are:
supports file upload
does not refresh browser on POST
uses Windows integrated security
works in IE 7/8 (does not need to support any other browsers)
What's the best way to accomplish this?
What I've tried:
Ideally this could be done in a simple AJAX call. However the current standard does not support sending binary data (supported in the XMLHttpRequest Level 2 standard, which is not implemented in IE yet).
So the next best thing is to POST to a hidden <iframe> element. Now I've tried this but the server on site B won't accept the data. I looked at the request and the only discrepancies that I found were the referer URL and the integrated authentication. The referer URL might have to be spoofed, which cannot be accomplished by this method. Also for some reason the authentication isn't being negotiated. I'm not 100% sure why.
Ideas:
I'm thinking of creating a proxy page on the server that I run (site A) that forwards the request to site B. Site A also uses integrated security. I don't see anything wrong with this, but I'm not sure if this is the best way to go. Will there be any authentication issues if I just forward the request over?
Using a proxy seems to be the only thing which can work in your case. If you want to make a get request then it can be done using JSONP provided that the server supports JSONP. To make the <iframe> hack work the server should send the headers as
Access-Control-Allow-Origin:*
which is not the case with you.
So using a proxy seems the solution
Related
I'm implementing Dropbox's "/list_folder/longpoll" call through their API in Javascript. As described here, the API call fails due to a cross-domain access control error.
Dropbox recommends a hacky workaround that goes against W3C standards: setting an invalid "Content-Type" header "text/plain; charset=dropbox-cors-hack", which somehow helps to comply with requirements for a "simple cross-site request" and therefore skips the cross-domain check. Because this is against the web standards, the browser modifies the header back to a valid form, and the API call always fails.
I discovered a couple possible workarounds for this:
Using own server to divert the call from browser->dropbox to browser->own server->dropbox. Make an ajax call to the server, server makes a cURL request to dropbox, everything works fine.
This method's drawback is that you have to actually have a capable server with spare resources to keep all your user's longpoll connections open. I wasn't able to implement this in PHP efficiently.
Using Javascript's new fetch() method instead of XMLHttpRequest. It seems to allow setting the invalid header, and the API call works fine. Setting a normal (not the hacky one) header results in a failed call.
The drawback of this method is browser support. Without the fetch polyfill only Chrome and Firefox supports this. Using the polyfill theoretically adds support for IE and Safari too. But because the polyfill is based on XMLHttpRequest, the headers are changed back to valid ones, as they would be when using plain XMLHttpRequest. Except for IE, where the invalid headers don't get changed back, because IE.
I went with the second workaround, so now I'm left without Safari support.
My question is this: how to solve this problem? Maybe by somehow making PHP handle long (1-2 minute) cURL calls more efficiently? Or maybe by somehow hacking my way into a cross-browser solution of setting an invalid Content-Type header?
I'm thinking about iframes, but this is getting a little ridiculous :)
I need to send and load JSON data to and from a PHP script on a different domain and while the variables were passed, nothing is returned.
domain1.com/display.php (has Jquery $post() routine to send and load data) to
domain2.com/data.php (php script outputs JSON data) <-- this receives data, but response is not sent to requesting script.
Of course this is due to browser security restricting cross site scripting stuffs.
I've read a bit about JSONP but that's just another extra step.
I remember when I used to do FLASH, i would just uload a policy file to the server on a different domain where I would load data from and everything would just work.
Is there anything like that for JavaScript? if not, WHY the HECK not?! Seems to me like it's a legit, hassle free solution, that's just about as secure as JSONP method, or even more so.
Regards
Since you say "it's Javascript that needs to load the data", I gather this is running in some browser. In this case, the browser is enforcing security, as fas as I know, and fiddling with the server( script)s will not help.
Chrome has a command-line option to turn off XS security (--disable-web-security), and Firefox has a setting in about:config (I think, can't find it right now... sorry).
But I guess there's reason to these security settings in the first place... ;-)
Are you trying to load it on the client? Using PHP+cURL it should be no problem on the server side. If you really need to load cross domain content on the client side you could use the Cross Domain jQuery plugin (uses YQL internally)
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'm working on the project where the client has the back-end code in ServerA, and my front-end code, which is supposed to talk to back-end via AJAX requests is on ServerB, and they are in different domains. Because of the same origin policy, I'm not able to make those requests successfully (neither POST nor GET). Is it possible to enable it somehow without changing the back-end code to handle the JSONP? eg., white list that particular domain, or something?
I tried to emulate this in my local network where the back-end code is running on 10.0.1.4 (different machine), and I'm accessing it from localhost (apache), but couldn't figure out anything that doesn't require using jsonp. When calls are made, I'm not even seeing anything in the logs in the back-end, but it works fine from the REST client and by just loading the URL for GET requests. How are public API requests implemented that are not using JSONP?
I need at least one method (POST or GET) to work. Thanks.
Is it possible to enable it somehow without changing the back-end code
to handle the JSONP? eg., white list that particular domain, or
something?
Yes, you could write a server side script on your domain that will serve as a bridge between your and the remote domain and then send an AJAX request to your script.
Don't expect miracles. If you don't have control over the remote domain you are busted. The same origin policy restriction that's built into browsers for security reasons busts you. Well, you could always write your own browser that doesn't implement this policy, but I think you get my point.
Common workarounds include JSONP and CORS but they involve control over the remote domain. If you don't have control then read the my previous sentence as well as my first sentence.
Here's a nice guide I invite you consulting that covers some common techniques allowing to achieve cross domain AJAX with jQuery. Then adapt the one that fits best your scenario. And there's always the heavy artillery solution that involves bridging the 2 domains with a server side script which works bullet-proof in 100% of the cases if none of the other workarounds help you.
Is it possible to enable it somehow without changing the back-end code to handle the JSONP? eg., white list that particular domain, or something?
Hmmm, mostly no. You must allow JSONP or "white list" things via CORS (which is very easy to do). Or you can use YQL as a cross-domain proxy.
Three solutions posted here:
http://devlog.info/2010/03/10/cross-domain-ajax/
I've tried the third option since it just worked for me.. and I didn't have to go through any extra stress as it just handled things just like a regular ajax call.
Updating answer as this was posted 2 years ago:
LINK ABOVE NO LONGER WORKS.
Server side proxy:
the old page also talks about using a server side proxy, which means your server makes a call to another server, grabs all the data and sends it off to a page resting on that server. There is no problem for one server to fetch data from another server. So then your page can make a regular ajax call to that server. I didn't go with this option as it required more manual labor. So I'd suggest going with the option detailed here:
JSONP with jQuery
Make sure the provider supports JSONP.
Set the dataType option to jsonp, and if the provider uses a different GET param other than 'callback', specify the jsonp option to that parameter name.
$.ajax({
// ... Use the AJAX utility as you normally would
dataType: 'jsonp',
// ...
});
jQuery will generate a unique callback name for this request (something like json1268267816). Thus, the reply from a web service would be something like:
json1268267816({'uid': 23, 'username': 'Chroder', 'name': 'Christopher Nadeau'});
But jQuery handles it all seamlessly, so you as the developer just handle it like a normal AJAX request using the same jQuery success/failure/complete callback hooks.
Drawbacks:
The first limitation to this method is that you have to rely on the provider to implement JSONP. The provider needs to actually support JSONP -- they need to wrap their JSON data with that callback function name.
Then the next limitation -- and this is a big one -- is that JSONP doesn't support POST requests. Since all data is passed in the query string as GET data, you are severely limited if your services require the passing of long data (for example, forum posts or comments or articles). But for the majority of consumer services that fetch more data than they push, this isn't such a big problem.
However,
Using a library like jQuery that supports JSONP, these details of inserting the special script tag and creating the special callback function are all taken care of automatically. Using a JS library, usually the only difference between JSONP and real AJAX is that you enable a 'jsonp' option.
DISCLAIMER: I've already looked at various approaches to solve my issue, so please read this before labeling this as a duplicate question
I have a javascript running on https://xyz.com which has to retrieve information from an application ABC running on the user's local machine say port 8080.
My constraints are that I cannot modify the HTTP headers emanating form the ABC nor do I want the user to install another application which will be a conduit to route my requests through to ABC.
Cross-Domain/Window Messaging Options
a) window.postMessage: Ruled out since I cannot have script running on the local machine
b) XDR Object (IE) or Access-Control-Allow-Origin (Firefox,Safari et al): Ruled out since I cannot modify the header
c) JSONP: Again this will not work since I am unable to enclose the response within the function name
As a workaround, only meant for testing I've added the http://xyz.com to the trusted list and have enabled Access Data Across Domains for sites on this list. AFAIK, this option is only available on IE 5+ browsers. This workaround allows me to send and receive messages from http://127.0.0.1:8080
My question is two-fold
1) If I were to continue with the above approach when I go into production what are the security implications that I'm exposing the user to? Can I plug those holes?
2) Are there any other options that I can pursue to achieve my objective.
PS: I would like to be as far away from ActiveX or Flash as possible, but in case that is the only workable alternative to my current approach then I'll have to toe the line
Cheers
If the local application could serve a single html document, to act as a bridge, then you could easily use Cross-Document Messaging (for instance with easyXDM) together with ajax requests from this document to do this. This is a very simple approach and one commonly used.
easyXDM actually comes with such a document, you can read about it here.
I think that the easiest would be to put a server script on https://xyz.com which will act as a bridge between the javascript file and ABC. Then the javascript file will simply send an AJAX request to it's own server script which will take care of fetching the information from the remote domain. The only other viable solution which would work among most browsers and which doesn't require using some client technology like Flash or ActiveX is JSONP but you have ruled this out because you have no control over the remote domain.