views:

763

answers:

5

We have an ASP.Net application hosted on our network and exposed to a specific client. This client wants to be able to import data from their own server into our application. The data is retrieved with an HTTP request and is CSV formatted. The problem is that they do not want to expose their server to our network and are requesting the import to be done on the client side (all clients are from the same network as their server).

So, what needs to be done is:

  1. They request an import page from our server
  2. The client script on the page issues a request to their server to get CSV formatted data
  3. The data is sent back to our application

This is not a challenge when both servers are on the same domain: a simple hidden iframe or something similar will do the trick, but here what I'm getting is a cross-domain "access denied" error. They also refuse to change the data format to return JSON or XML formatted data.

What I tried and learned so far is:

  1. Hidden iframe -- "access denied"
  2. XMLHttpRequest -- behaviour depends on the browser security settings: may work, may work while nagging a user with security warnings, or may not work at all
  3. Dynamic script tags -- would have worked if they could have returned data in JSON format
  4. IE client data binding -- the same "access denied" error

Is there anything else I can try before giving up and saying that it will not be possible without exposing their server to our application, changing their data format or changing their browser security settings? (DNS trick is not an option, by the way).

+1  A: 

JSONP might be the answer for you if they can server data in a JSON format. Other than that you will always run into Same Origin Policy issues with cross-domain calls. Have you looked into doing Server-side calls to do HTTP requests to their server?

AutomatedTester
No, their server is not accessible from our server.
vit
+1  A: 

Your client is JavaScript served by your application, right?

Your client can then only send requests to your applciation (cross-site scripting prevention), that the error you are seeing?

Assuming yes, then a solution is to have your application offer a "proxy" service. You browser code can ask your server for some data. Your server is free to issue an Http request to any server it likes (no browser to object). So you implement a little service to go get that cvs data and present it to your application.

You might even choose to map that CSV data to JSON if it's your client that's consuming it.

djna
Proxy will not work as their server is only visible from their own network and is not accessible from our server.
vit
So their browsers can see you, and their servers. But you can't see their servers. (apologies you did say all that in the question.) Pretty tough to get past.
djna
A: 

Can't you host just the JS file on their server? This should allow script in that file to make ajax calls back to their server.

JonoW
No - the same-origin policy relates to the domain the *page* was served from, not the domain the *script* was served from.
NickFitz
You're right, shame on me :)
JonoW
A: 

You can try though the flash. If you will put this yourdomain.com/crossdomain.xml in you root you will be able to make cross domain requests from mysite.com.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"&gt;
<cross-domain-policy>
<allow-access-from domain="www.mysite.com" to-ports="25" />
</cross-domain-policy>
Eldar Djafarov
Shouldn't it be placed on the server I'm requsting data from, rather then our own server?
vit
As i understood you have no direct access to their server. So if there is a page from their domain with necessary info in CSV, this page can send the data to your domain with flash.
Eldar Djafarov
+1  A: 

It might be too late for your client, but since you have have control over both domains, you can try EasyXDM. It's a library which wraps cross-browser quirks and provides an easy-to-use API for communicating in client script between different domains using the best available mechanism for that browser (e.g. postMessage if available, other mechanisms if not).

Caveat: you need to have control over both domains in order to make it work (where "control" means you can place static files on both of them). But you don't need any server-side code changes.

Justin Grant
Hi, I'm not working there anymore and I don't even remember all the details of the problem, but thanks for good link! :)
vit
Anyway, since this would have solved the original problem, I will accept this as an answer.
vit