在MacOSX上，当指定无效的身份验证凭据时，QNetworkAccessManager进入无限循环 [英] On MacOSX, QNetworkAccessManager gets into an infinite loop when invalid auth credentials specified

问题描述

在我的跨平台应用程序中，我使用QNetworkAccessManager将HTTP请求发送到需要身份验证的HTTP服务.我最近升级到了QT5，在MacOSX上令我感到完全惊讶的是，在某些情况下，我的应用程序将尽快向我的服务发送大量请求.

In my cross-platform app, I use QNetworkAccessManager to send HTTP requests to my HTTP service that requires authentication. I recently upgraded to QT5, and to my complete surprise on MacOSX my app would send a massive amount of requests to the my service as fast as possible in some scenarios.

进行一些调试之后，事实证明只有在我的请求中指定了错误的身份验证凭据时，才会发生这种情况.如果在我的HTTP请求中指定了无效的用户名/密码，QNetworkAccessManager将无限期地向我的服务重新发送请求.

After doing some debugging, it turns out that this would only happen when I specify bad auth credentials in my requests. QNetworkAccessManager would indefinitely resend requests to my service if invalid username/password were specified in my HTTP requests.

我的代码在以前的QT版本中已经使用了很长时间，所以我认为QT5必须使用它.

My code has worked for a long time in previous QT versions, so I decided it has to be something with QT5.

推荐答案

我偶然发现了QT5中添加的以下增强功能: https://bugreports.qt.io/browse/QTBUG-22033

I stumbled upon a following enhancement that was added in QT5: https://bugreports.qt.io/browse/QTBUG-22033

基本上，此增强功能背后的想法是，如果中间代理需要身份验证凭据，则检查钥匙串中的用户名/密码.事实证明，这是错误实现的，并且此代码已添加到QNetworkAccessManager :: authenticationRequired()信号中，而不是添加到proxyAuthenticationRequired()信号中.

Basically, the idea behind this enhancement os to check keychain for username/password if it intermediate proxy is requiring auth credentials. It turns out this was badly implemented, and this code has been added to the QNetworkAccessManager::authenticationRequired() signal, instead of being added to proxyAuthenticationRequired() signal.

有关此问题的有趣部分是，我没有为我的应用程序设置代理，也没有为我使用的QNetworkAccessManager设置代理.这使得这个问题很难调试！

The interesting part about this problem is that I don't set proxy for my application nor QNetworkAccessManager that I use. Which makes this problem so hard to debug!

由于位置不正确，任何"authenticationRequired"信号都会发生此钥匙串查询".底层的getProxyAuth()方法正在使用空白主机名调用"SecKeychainFindInternetPassword"，该主机名与我的钥匙串中的第一个"Internet密码"匹配，并使用它使用此新凭据将请求发送到我的服务.想象一下，当我看到自己的其他/个人密码之一发送到我的HTTP服务时，我感到惊讶！

Because of the bad placement, this "keychain querying" is happening with any authenticationRequired signal. The underlying getProxyAuth() method is calling "SecKeychainFindInternetPassword" with blank hostname which is matching a first "Internet Password" from my keychain and using it to send a request to my service with this new credentials. Imagine my surprise when I saw one of my other/personal passwords being sent to my HTTP service!

不仅这是一个安全问题，而且还会在您的应用中引起无限循环.我为此打开了一个有关QT的错误: https://bugreports.qt.io/browse/QTBUG -30434

Not only this is a security issues, but it cause an infinite loop in your app. I opened a bug with QT about this: https://bugreports.qt.io/browse/QTBUG-30434

有临时解决方案吗?有！我寻找了暂时解决此问题的方法.这是一个讨厌的黑客.但这一直有效，直到QT家伙连续获得成功为止.这种黑客之所以行之有效，是因为它可以确保"SecKeychainFindInternetPassword"与钥匙串中的任何条目都不匹配，从而跳过该钥匙串查询".

Is there a temporary solution? There is! I looked for a workaround to this issue for while. It is a nasty hack. But it works until QT guys get their ducks in a row. This hack works because it ensures that "SecKeychainFindInternetPassword" does not match any entries in the keychain, and therefore skipping that "keychain query".

基本上，我将代理主机名设置为"，而不是"，这将防止任何匹配导致我的应用程序中发生infite循环.

Basically I am setting proxy hostname to " " instead of "" which will prevent any matching that causes an infite loop in my app.

解决方法:

 QNetworkProxy proxy = manager_->proxy();
 proxy.setHostName(" ");
 manager_->setProxy(proxy);

我希望在下一个版本的QT中能够解决此问题，所以我可以删除此可怕的骇客.

I hope this is resolved in the next version of QT, so I can remove this horrible hack.

这篇关于在MacOSX上，当指定无效的身份验证凭据时，QNetworkAccessManager进入无限循环的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！