对不受信任（自签名）HTTPS 的 AJAX 调用会默默失败
我想对使用自签名证书的安全服务器进行 AJAX 调用。在使用我的应用程序的环境中，这很好——我可以向用户提供 CA 证书并让他们在使用应用程序之前安装它。但是，有时，用户会在安装证书之前尝试访问该应用程序。在这些情况下，应用程序会默默地失败——至少在 Firefox 中（最常见的问题情况），看起来调用会默默地终止，甚至没有触发错误处理程序。 FWIW，如果用户访问服务器上的实际页面，他们会收到证书警告。
我可以破解一个解决方法 - 例如，发出心跳/ping 请求并设置一个看门狗计时器来查看服务器是否及时响应 - 但这看起来很糟糕。我希望能够提前测试连接。确保您想要交谈的服务器拥有来自 Javascript 的可信证书的“正确”方法是什么？如果有什么区别的话，我将通过 JQuery 执行 AJAX 请求。
更新：这里有一个很棒的妙语。事实证明，AJAX 根本不是问题所在。根据症状，我确信它与自签名证书有关，但缺乏 AJAX 错误令人不安，尤其是。给出下面答案中链接的规范。另一位团队成员指出了这一点：AJAX 错误处理程序没有启动，因为 JQuery 从未加载！我们包含了来自我们网站的另一个子域的 JQuery，该子域也托管在 HTTPS 上 - 用户为 ourService.example.com 添加了例外，但没有为 js.example.com 添加了例外。显然，如果您将
{/服务台}
I want to make AJAX calls to a secure server that uses a self-signed certificate. In the environment where my app is being used, this is fine -- I can provide the CA cert to users and have them install it before using the app. However, sometimes, a user tries to visit the app before installing the certs. In these cases, the app silently fails -- at least in Firefox (most common case of the problem), it appears that the call silently dies, without even firing off the error handler. FWIW, if the user visits an actual page on the server, they get a cert warning.
I could hack in a workaround -- say, make a heartbeat/ping request and set up a watchdog timer to see if the server responds in time -- but that seems, well, hacky. I'd prefer to be able to test the connection ahead of time. What's the "right" way to make sure the server you want to talk to has a trusted cert from within Javascript? If it makes any difference, I'm doing my AJAX requests via JQuery.
UPDATE: There's an awesome punchline here. Turns out, AJAX was not the problem at all. I was sure based on the symptoms that it was related to the self-signed certs, but the lack of AJAX error was disturbing, esp. given the spec linked to in the answer below. Another team member nailed it: the AJAX error handlers weren't firing off because JQuery was never loaded! We were including JQuery from another subdomain of our site, also hosted on HTTPS -- and users had added exceptions for ourService.example.com but not js.example.com. Apparently if you point a <script> tag at non-trusted secure connection, that fails silently as well.
{/headdesk}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
XMLHttpRequest（AJAX 请求）仅允许在同源服务器上使用。这意味着目标URL 的scheme://host:port 部分必须与当前文档的scheme://host:port 部分匹配。根据规范，您甚至不应该被允许从非 SSL URL 向 SSL URL 发出请求。
我看到的不太黑客的解决方案是，您只需将所有用户强制重定向到 SSL 站点。这样，他们将被迫在发出任何 AJAX 请求之前看到证书警告。
注意：规范还规定，如果 TLS 握手失败（我认为这种情况在某种程度上属于这种情况），它应该抛出 NETWORK_ERR （代码 19）异常。您可以尝试在发起 AJAX 请求时捕获异常。有关更多详细信息，请参阅有关错误处理的规范。
XMLHttpRequests (AJAX requests) are only permitted on same-origin servers. That means the scheme://host:port part of the target URL has to match that of the current document. According to the spec, you shouldn't even be allowed to make a request on the SSL URL from the non-SSL one.
The less hackish solution that I see is that you just force-redirect all users to the SSL site. That way they will be forced to see the certificate warning before any AJAX request can be made.
Note: The spec also says that in case of TLS handshake failure (which I assume this case falls under, in a way) it should throw a NETWORK_ERR (code 19) exception. You could try to catch the exception when initiating the AJAX request. Refer to the spec on error handling for more details.