通过https网站与localhost上的http服务器进行通信，跨域

Question

So I have a GWT webapp that needs to communicate with a desktop application. To accomplish this, the desktop program starts up a webserver at a given port (say, http://localhost:9000 ).

I have implemented JSON-P communication to get around the Cross-Domain filters, which works fine when testing locally (webapp runs at http://localhost:8888 ). The problem is, the production website is served over https, and no browser will allow you to request javascript over http from https.

So I've tried a few things.

I have set the "Access-Control-Origin: *" header using Java's HttpServletResponse.addHeader("Access-Control-Allow-Origin", "*") on both the server that serves the GWT javascript and the server that the javascript is trying to make requests to, and making HTTP requests, but that gets blocked by same origin filters (presumable because I'm trying to make request from https to http.)

I have tried to use the Json-P communication from a new Window (created by calling $wnd.open) without a URL hoping that it would load over http, but it is loaded over https, so I ran into the same problem as before.

Is there any way to make a cross domain request from javascript served over https to http? There isn't any feasible way to run https on the localhost (self-signed cert gets blocked when making JSON-P requests.)

Answer 1

Assuming that the computer you are deploying to has internet access, the best solution to this problem is to register a subdomain on your main site where the webapp is hosted (for example, localhost.example.com) and setup the DNS entries to point to 127.0.0.1 . You can then get a signed https certificate for localhost.example.com and distribute that certificate with your application.

Words of warning:

• Because the certificate is distributed with your application, it isn't secret, so make sure not to provide a certificate for *.example.com or anything silly like that. Fortunately, an attacker needs to run a server on the local machine to exploit it, in which case they already have access to all of your cookies and stuff.
• If/when your certificate expires, things could break. This may require having your client app download the certificate from your web server. The security implications of this should be no worse than distributing it in the binary.
• If you are very security-sensitive, using an entirely separate domain (localhostexample.com) could protect against future exploits or bugs.