Hosting static content on different domain from webservices, how to avoid cross-domain?

Question

We've recently been working on a fairly modern web app and are ready to being deploying it for alpha/beta and getting some real-world experience with it.

We have ASP.Net based web services (Web Api) and a JavaScript front-end which is 100% client-side MVC using backbone.

We have purchased our domain name, and for the sake of this question our deployment looks like this:

webservices.mydomain.com (Webservices)

mydomain.com (JavaScript front-end)

If the JavaScript attempts to talk to the webservices on the sub-domain we blow up with cross domain issues, I've played around with CORS but am not satisfied with the cross browser support so I'm counting this out as an option.

On our development PC's we have used an IIS reverse proxy to forward all requests to mydomain.com/webservices to webservices.mydomain.com - Which solves all our problems as the browser thinks everything is on the same domain.

So my question is, in a public deployment, how is this issue most commonly solved? Is a reverse proxy the right way to do it? If so is there any hosted services that offer a reverse proxy for this situation? Are there better ways of deploying this?

I want to use CloudFront CDN as all our servers/services are hosted with Amazon, I'm really struggling to find info on if a CDN can support this type of setup though.

Thanks

Perhaps my personal implementation is too simple (and if so I'd also be interested in others' comments). I guess what's missing is what is your data transport between the front/back? In my simple implementation, the front communicates with the back (WCF service) via JSONP for "real" cross domain implementation. If I need to "proxy", then its an "app proxy" - front at mydomain.com will talk to a handler (i.e. ashx) on mydomain.com which "proxies" the http request to WCF at myotherdomain.com. — EdSF, Mar 17 '12 at 05:37
Are you using JQuery or pure javascript? ( in case of JQuery,you could use this: http://usejquery.com/posts/the-jquery-cross-domain-ajax-guide ) — ONOZ, Mar 26 '12 at 09:51
For WebAPI, you can review this post on enabling CORS with JSONP that should work well across browsers http://goo.gl/KjT6y — cecilphillip, Mar 26 '12 at 14:36

score 1 · Answer 1 · answered Jun 13 '12 at 04:26

1

To allow this Web Service to be called from script, using ASP.NET AJAX, add the following line to the first web service code-behind :

[System.Web.Script.Services.ScriptService]

answered Jun 13 '12 at 04:26

Đình Hoàn

11
1

score 1 · Answer 2 · answered Mar 26 '12 at 19:22

1

What you are trying to do is cross-subdomain calls, and not entirely cross-domain. That are tricks for that: http://www.tomhoppe.com/index.php/2008/03/cross-sub-domain-javascript-ajax-iframe-etc/

As asked how this issue is most commonly solved. My answer is: this issue is commonly AVOIDED. In real world you would setup your domains such as you don't need to make such ways around just to get your application running or setup a proxy server to forward the calls for you. JSONP is also a hack-ish solution.

answered Mar 26 '12 at 19:22

Israel Lot

653
1
9
16

Out of curiosity, how would I set up my domains as to avoid this issue? In my mind, "web applications" aren't ready for prime time yet i.e. You cannot build and run a pure javascript web app yet. CORS = Bad support, JSONP = Hack/Limited functionality, Inter-iframe coms = Hack. – Tyler Mar 26 '12 at 21:53
Simply set your web service as mydomain.com/service with a load balancer with reverse proxy and all problems are gone. – Tisho Jun 13 '12 at 10:48

score 0 · Answer 3 · answered Apr 21 '12 at 19:36

You have 2/3 layers

in the web service code-behin class, add this atribute : <System.Web.Script.Services.ScriptService()> _

maybe you need to add this in the System.web node of your web.config:

<webServices>
        <protocols>
          <add name="AnyHttpSoap"/>
          <add name="HttpPost"/>
          <add name="HttpGet"/>
        </protocols>
      </webServices>

In the client-side interface

-Add web reference to the service on the subdomain (exmpl. webservices.mydomain.com/svc.asmx) Visual studio make the "proxy class"

-add functionality in the masterpage's|page's|control's code behin -Simply call this functions from client-side

You can use AJAX functionality with scriptmanager or use another system like JQuery.

If your main website is compiled in .NET 3.5 or older, you need to add a reference to the namespace System.Web.Extensions and declare it in your web.config file.

score 0 · Answer 4 · answered Jun 08 '12 at 17:51

If you have the bandwidth (network I/O and CPU) to handle this, a reverse proxy is an excellent solution. A good reverse proxy will even cache static calls to help mitigate the network delay introduced by the proxy.

The other option is to setup the proper cross domain policy files and/or headers. Doing this in some cloud providers can be hard or even impossible. I recently ran into issues with font files and IE not being happy with cross domain calls. We could not get the cloud storage provider we were using to set the correct headers, so we hosted them locally rather than have to deal with a reverse proxy.

score 0 · Answer 5 · edited May 23 '17 at 11:56

easyXDM is a cross domain Javascript plugin that may be worth exploring. It makes use of standards when the browser supports them, and abstracts away the various hacks required when the browser doesn't support the standards. From easyXDM.net:

easyXDM is a Javascript library that enables you as a developer to easily work around the limitation set in place by the Same Origin Policy, in turn making it easy to communicate and expose javascript API’s across domain boundaries.

At the core easyXDM provides a transport stack capable of passing string based messages between two windows, a consumer (the main document) and a provider (a document included using an iframe). It does this by using one of several available techniques, always selecting the most efficient one for the current browser. For all implementations the transport stack offers bi-directionality, reliability, queueing and sender-verification.

One of the goals of easyXDM is to support all browsers that are in common use, and to provide the same features for all. One of the strategies for reaching this is to follow defined standards, plus using feature detection to assure the use of the most efficient one.

To quote easy XDM's author:

...sites like LinkedIn, Twitter and Disqus as well as applications run by Nokia and others have built their applications on top of the messaging framework provided by easyXDM.

So easyXDM is clearly not some poxy hack, but I admit its a big dependency to take on your project.

The current state of the web is that if you want to push the envelop, you have to use feature detection and polyfills, or simply force your users to upgrade to an HTML5 browser. If that makes you squirm, you're not alone, but the polyfills are a kind of temporary evil needed to get from where the web is to where we'd like it to be.

Hosting static content on different domain from webservices, how to avoid cross-domain?

6 Answers6