views:

2591

answers:

2

I have developed a set of apis that live on an asp.net mvc application, but will be consumed from a browser accessing our main site (which lives on a LAMP stack).

The domain names look like this:

http://www.mainsite.org

API's

http://apis.www.mainsite.org (originally, apis.mainsite.org, but I made the modification in an attempt to fix the problem)

I make a $.ajax() request to the api which in turn sends plain html to dump an input form into a div.

The configration runs fine when I run from a sample host page that lives on my apis site, but when I put the same page on a site outside of apis.www.mainsite.org, I get a "permission denied" error in IE on the first request to the service.

I've seem a few resources that say I must implement JSONP in order to get this to work correctly and make the cross-domain script call that way - but I am hopeful that I can enable that functionality while still returning html instead of JSON.

Any suggestions would be greatly appreciated.

One other question - any idea why an XMLhttp request from http://mysite.org to http://api.mysite.org would be considered cross domain? Does any change in the domain name make it a cross domain call?

It seems like a fairly common scenario to separate the domain for the api from the main content domain and I am hopeful that I am just missing something simple.

Best regards and thanks for your time.

Hal

+2  A: 

This is called 'Same Origin Policy', which means that Javascript cannot access pages outside of its domain.

Yes, any change will trigger it to be a cross domain call. I suggest making a symbolic link to a directory called /api that would make the directory forward to wherever you store the api.example.com files. It would make it look exactly alike. So api.example.com and example.com/api link to the same folder. That would probably fix your situation.

Also, I find that most sites I visit use an API folder to house their API instead of a subdomain, but then again I haven't really worked with companies.

Chacha102
If the web site and the API were using the same stack, I could see doing this, but the API is ASP.NET MVC and the web site is served with a LAMP stack. Maybe you could get this to work, but it would be better to implement the API on the LAMP stack instead.
tvanfosson
Another idea is to put a proxy, which is a PHP script that takes the Javascript calls, and then goes out to the API, gets the data, and gives it back to the Javascript client. You could even implement caching.
Chacha102
Our business rules will end up living under the API and we will be forced to keep that on ASP.NET MVC (under Windows stack), so I can't rebuild the API on LAMP. However, I may take a look at generating a PHP proxy to consume my services, which I could provide to our designers. BTW - anyone know how Google and other larger api providers get away with it? Do they allow only JSONP interaction?
Hal
The first two answers and subsequent comments were both very helpful. I'll mark the first one posted as accepted. Thanks a ton.
Hal
+2  A: 

The following post might shed more light on a script tag hack technique:

http://stackoverflow.com/questions/926137/why-dont-i-get-a-same-origin-policy-warning-when-using-the-google-maps-api

In short, you cannot make cross-domain calls using XmlHttpRequest (which is what jquery and ext-js use). The <script> tag is immune from such rules. The trick is to put in a URL with parameters whose page returns JSON back using those parameters to formulate a call to a callback in your JavaScript code.

EDIT: To answer your other question, the domain portion of your URL must match exactly. See the following Wikipedia article for examples of cross-domain versus same-domain calls:

http://en.wikipedia.org/wiki/Same_origin_policy

j0rd4n
The "script hack technique" is JSONP.
tvanfosson