2

私のクロスプラットフォーム アプリでは、QNetworkAccessManager を使用して、認証が必要な HTTP サービスに HTTP 要求を送信します。私は最近 QT5 にアップグレードしましたが、MacOSX で完全に驚いたことに、シナリオによっては、アプリが大量のリクエストをサービスにできるだけ速く送信していました。

デバッグを行った後、これは、リクエストで不正な認証資格情報を指定した場合にのみ発生することがわかりました。HTTP リクエストで無効なユーザー名/パスワードが指定されている場合、QNetworkAccessManager は無期限にリクエストをサービスに再送信します。

私のコードは以前の QT バージョンで長い間機能していたので、QT5 で何かする必要があると判断しました。

4

1 に答える 1

7

QT5 で追加された次の機能強化に出くわしました: https://bugreports.qt.io/browse/QTBUG-22033

基本的に、この拡張機能の背後にあるアイデアは、中間プロキシが認証資格情報を必要とする場合にユーザー名/パスワードのキーチェーンをチェックすることです。これは正しく実装されていないことが判明し、このコードは proxyAuthenticationRequired() シグナルに追加される代わりに、QNetworkAccessManager::authenticationRequired() シグナルに追加されました。

この問題の興味深い点は、アプリケーションのプロキシも、使用している QNetworkAccessManager も設定していないことです。これにより、この問題のデバッグが非常に困難になります。

配置が悪いため、この「キーチェーンのクエリ」は authenticationRequired シグナルで発生しています。基礎となる getProxyAuth() メソッドは、キーチェーンの最初の「インターネット パスワード」と一致する空白のホスト名で「SecKeychainFindInternetPassword」を呼び出し、それを使用してこの新しい資格情報でサービスにリクエストを送信します。HTTP サービスに送信された他の/個人用パスワードの 1 つを見たときの驚きを想像してみてください!

これはセキュリティ上の問題であるだけでなく、アプリで無限ループを引き起こします。これについて QT でバグを開きました: https://bugreports.qt.io/browse/QTBUG-30434

一時的な解決策はありますか？がある！しばらくの間、この問題の回避策を探しました。それは厄介なハックです。しかし、QTの人たちがアヒルを一列に並べるまではうまくいきます. このハックは、「SecKeychainFindInternetPassword」がキーチェーンのどのエントリにも一致しないことを保証し、その「キーチェーン クエリ」をスキップするために機能します。

基本的に、プロキシのホスト名を "" ではなく " " に設定しています。これにより、アプリで無限ループを引き起こす一致が防止されます。

回避策:

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

これが QT の次のバージョンで解決されることを願っています。そうすれば、この恐ろしいハックを取り除くことができます。

于 2013-03-29T16:33:14.707 に答える