AJAX, Subdomains, and SSL

Question

I have a site, foo.com, that makes ajax requests to bar.foo.com. Will this work.

Also, if foo is a secure connection, https, does bar.foo.com need to be https too? Can these two sites use different certificates?

Answer 1

Most browsers will, depending on their security/privacy setting, block any outside call made - and only allow AJAX calls made to the same domain. Even subdomains are blocked, because on shared environments they might pose a real threat.

In short: only make AJAX calls through the same domain (perhaps call a page, that in turn calls another page from another domain - through curl/fopen/...), or you'll run into troubles. That also answers your SSL question - it doesn't matter what SSL you're using, or whether they're the same - calls will get blocked, despite the SSL.

Answer 2

Yes you can get different certs for both domains. It's all in how you decide to configure it.

You can configure a web server for foo.com and you can open port 80 for non secure and port 443 for secure and use both.

You can configure a different web server for bar.foo.com and do the same port configs.

If you need to ensure that you are secure on both then you need to get certs for each different domain.

You might be able to buy a *.foo.com cert that would enable you to copy the one cert to the other site and use it.

Regardless if your request links to http://bar.foo.com you will not have a secure connection.

You have to have the http"s" in there to tell the webserver to use port 443 and attempt to validate the cert.

All certs really do is say that the source is trusted. Even if it isn't trusted and you do use http"s" and there is a lock on the browser your data is encrypted anyway.

Answer 3

With plain-http AJAX: You are talking about doing cross-domain XMLHttpRequest, which is not permitted by browsers. There's a W3C proposal pending to implement this in a secure way in the future (partially implemented by IE8, IIRC), but it's definitely not possible at present.

There are, however, workarounds for doing it securely: Subspace (which uses iframes and document.domain), the fragment identifier technique (again, uses iframes) and window.name technique (again, iframes!).

As far as SSL goes, you can buy separate certificates for the domain and subdomain, or a single wildcard (*.foo.com) cert that covers them both (naturally, the wildcard cert will be more expensive).

If you have an HTTPS page that requests items from other domains, all will be well as long as everything is HTTPS. That means that if you use one of the iframe workarounds, you have to specify an https:// scheme URL in the src attribute of the iframe.

A final, less efficient, workaround is to have a script on https://foo.com that proxies requests to insecure http://bar.foo.com. (This also solves the XHR cross-domain problem, so you can ignore the other workarounds.) Of course, that means you're sending the XHR request to https://foo.com/someurl, it's then hitting http://bar.foo.com/someurl, receiving the response and sending it back to the browser, so performance-wise you're much better off just moving the server-side functionality of bar.foo.com onto foo.com, if you have that option. But if you can't move the server script, then proxying is the way to go.

EDIT: I changed the last 3 grafs after doing some extra testing and getting an iframe AJAX workaround (the #fragmentidentifier one) to work across different HTTPS domains. You can do SSL cross-domain AJAX using iframes as long as everything is https and the https scheme is used in the iframe src. Summarizing:

1. Short answer: no, true cross-domain XHR not allowed
2. Workaround with iframes: more efficient, need 2 SSL certs (or wildcard cert), somewhat complicated
3. Workaround with proxy: less efficient, can do with 1 or 2 SSL certs (1 with backend request to bar.foo.com via http), somewhat complicated

Answer 4

You can combine JavaScript TLS and Flash to accomplish secure cross-domain requests. This way your visitors go to https://foo.com and you can make XmlHttpRequests to https://bar.foo.com. You can do the same thing with regular http.

You will need to purchase an SSL certificate that your visitor's browsers will trust for foo.com, but you can generate your own SSL certificates for bar.foo.com, bar2.foo.com, etc. A more expensive alternative to generating your own SSL certificates (which is free) is to buy a wildcard SSL certificate for *.foo.com. But if you're only doing cross-domain requests to those sites via foo.com then you don't need to spend that extra cash.

Check out the opensource Forge project on github:

http://github.com/digitalbazaar/forge/blob/master/README

The blog links at the end provide a more in-depth explanation.