AJAX、子域和 SSL
我有一个网站 foo.com，它向 bar.foo.com 发出 ajax 请求。 这行得通吗？
另外，如果 foo 是安全连接 https，那么 bar.foo.com 也需要是 https 吗？ 这两个站点可以使用不同的证书吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
使用纯 http AJAX：您正在谈论进行跨域 XMLHttpRequest，这是浏览器不允许的。 有一个 W3C 提案待定，以便将来以安全的方式实现此功能（部分由 IE8、IIRC 实现） ，但目前肯定是不可能的。
然而，有一些安全的解决方法：Subspace（使用 iframe 和
document.domain），片段标识符技术（再次使用 iframe）和window.name技术（再次强调，iframe！）。就 SSL 而言，您可以为域和子域购买单独的证书，或者购买涵盖这两个域的单个通配符 (*.foo.com) 证书（当然，通配符证书会更昂贵）。
如果您有一个 HTTPS 页面请求来自其他域的项目，那么只要一切都是 HTTPS，一切都会很好。 这意味着，如果您使用 iframe 解决方法之一，则必须在 iframe 的
src属性中指定https://方案 URL。最后一个效率较低的解决方法是在
https://foo.com上使用一个脚本来代理对不安全的http://bar.foo.com的请求。 （这也解决了 XHR 跨域问题，因此您可以忽略其他解决方法。）当然，这意味着您将 XHR 请求发送到https://foo.com/someurl，然后，它会点击http://bar.foo.com/someurl，接收响应并将其发送回浏览器，因此在性能方面，您最好只移动服务器端功能将 bar.foo.com 转移到 foo.com（如果您有此选项）。 但如果您无法移动服务器脚本，那么代理就是可行的方法。编辑：在做了一些额外的测试并获得 iframe AJAX 解决方法（#fragmentidentifier 之一）以跨不同的 HTTPS 域工作后，我更改了最后 3 个 graf。 您可以使用 iframe 进行 SSL 跨域 AJAX，只要一切都是
https并且在 iframesrc 中使用。 总结：https方案iframes：更高效，需要2个SSL
证书（或通配符证书），有点
使用代理的复杂
效率较低，可以使用 1 或 2
SSL 证书（1 个通过 http 向 bar.foo.com 发出后端请求），有点复杂
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) andwindow.nametechnique (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 thesrcattribute of the iframe.A final, less efficient, workaround is to have a script on
https://foo.comthat proxies requests to insecurehttp://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 tohttps://foo.com/someurl, it's then hittinghttp://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
httpsand thehttpsscheme is used in the iframesrc. Summarizing:iframes: more efficient, need 2 SSL
certs (or wildcard cert), somewhat
complicated
less efficient, can do with 1 or 2
SSL certs (1 with backend request to bar.foo.com via http), somewhat complicated
大多数浏览器将根据其安全/隐私设置阻止任何外部调用，并且只允许对同一域进行 AJAX 调用。 甚至子域也被阻止，因为在共享环境中它们可能会构成真正的威胁。
简而言之：仅通过同一域进行 AJAX 调用（可能调用一个页面，该页面又从另一个域调用另一个页面 - 通过curl/fopen/...），否则您会遇到麻烦。 这也回答了您的 SSL 问题 - 无论您使用什么 SSL，或者它们是否相同 - 尽管使用了 SSL，呼叫都会被阻止。
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.
是的，您可以获得两个域的不同证书。 这完全取决于您决定如何配置它。
您可以为 foo.com 配置 Web 服务器，并且可以打开非安全端口 80 和安全端口 443，并使用两者。
您可以为 bar.foo.com 配置不同的 Web 服务器并执行相同的端口配置。
如果您需要确保两个域的安全，那么您需要为每个不同的域获取证书。
您也许可以购买 *.foo.com 证书，这样您就可以将一个证书复制到另一个站点并使用它。
无论您的请求是否链接到 http://bar.foo.com，您都不会拥有安全连接。
您必须在其中添加 http"s" 来告诉网络服务器使用端口 443 并尝试验证证书。
所有证书真正要做的就是表明来源是可信的。
即使它不受信任并且您确实使用 http"s" 并且浏览器上有锁，您的数据无论如何都会被加密。
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.
您可以结合JavaScript TLS和Flash来完成安全的跨域请求。 这样，您的访问者就会转到 https://foo.com，您可以向 https://bar.foo.com。 您可以使用常规 http 执行相同的操作。
您需要为 foo.com 购买访问者浏览器信任的 SSL 证书，但您可以为 bar.foo.com、bar2.foo.com 等生成您自己的 SSL 证书。这是生成您自己的 SSL 证书的更昂贵的替代方案SSL证书（免费）是为*.foo.com购买通配符SSL证书。 但如果您只是通过 foo.com 向这些网站发出跨域请求，那么您就不需要花费额外的现金。
查看 github 上的开源 Forge 项目：
http://github.com/digitalbazaar/forge /blob/master/README
最后的博客链接提供了更深入的解释。
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.
是的，您当然可以进行跨域 ajax 提交。 我们使用 ssl.com 通配符证书 进行了完全相同的设置，但您可以在2 个站点。
基本上你会使用 JSONP（yahoo、google、fb 等都使用这个）。 返回值被包装在一个函数 amd 中，看起来像
Yes you most certainly can do cross domain ajax submits. We did the exact same setup using an ssl.com wildcard cert but you can use 2 standard certs on 2 sites.
Basically you would use JSONP (yahoo, google, fb, etc use this). The return value is wrapped in a function amd looks like