Requests: verify = Falseおよびrequests.packages.urllib3.disable_warnings（）

warningsモジュールを使用すると、これらをグローバルレベルで無効にできると思います。 さらに、ロギングを操作するには（私が正しく覚えている場合）、 urllib3にアクセスする必要があります（そしてそれを文書化します）ので、HTTPSの証明書検証を使用しないユーザーのためにこれを文書化することに反対しません接続。

私はこれらの警告をそのままにしておくことに強く賛成です。 はい、彼らは迷惑ですが、理由もあります。 どちらかといえば、私はそれをオフにして、私たちのものと交換したいと思っています！ = P

この時点で、 @ Lukasaと私がこの機能で-1であることはかなり明白です。 @kennethreitz @shazowご意見はありますか？

警告が重要であることにある程度同意しますが、考慮しなければならない要素は複数あると思います。

開発者の観点からは、私がこれについて知っていることを知っているので、気が向いたらこれをオフにすることができます。 私はパッケージに慣れていないので、ドキュメントを読んだときに警告で、そのソリューションは実際には機能しませんでした。 @Lukasaがrequests固有の何かを作ることについて提示したアイデアが好きです。

ユーザーの観点から、私pip今日pyvmomiをpipとともにインストールしました。これは、内部でrequestsを使用します。 requestsがサイレントサポートライブラリである場合にユーザーに返されるのは、実際には不透明なエラーです。

はい、 requests.packages.urllib3.disable_warnings()は、警告モジュールのフィルタリングを使用してオフにするためのショートカットです。

この影響について何らかの警告を出すことを強くお勧めします。 urllib3を伝播させる場合は+0.5、努力を加えてリクエスト固有のものを追加する場合は+1。 -警告がない場合は-1。

必要に応じて、urllib3警告メッセージを構成可能にし、それをオーバーライドして、他の方法で同じロジックに便乗できるようにすることができます。

繰り返しになりますが、私はこのメッセージをユーザーに敵対的であるとは考えていません。非常に価値があると思います。 これで、pyvmomiがTLS証明書の検証をオフにしたことがわかりました。これは、かなり重要な情報です。

とは言うものの、私はそれを沈黙させるためのより多くの要求を持っていることに反対しません。

ええ、本当にこれはpyvmomiバグだと思います。 このように困惑したくない場合は、ツールで警告を無効にする必要があります。 ツールが証明書の検証を実行していないため、一部のツールが行っている接続がMITM攻撃にさらされる可能性があることをユーザーに警告することは、私たちの仕事ではありません。

ディスカッションの皆さん、ありがとう！ 皆さんのコメントに感謝し、物事が行われる方法の価値とその理由を理解するのを手伝ってくれました。 もっと一般的なケースを見るのに苦労していました！ :)

時間が許す限り、今日はパッチに取り組み、「requests-y」の方法で沈黙させます。 フィードバックは大歓迎です！

@invisiblethreat質問がある場合は、IRCに気軽に

リクエストがWebhookで使用される場合を検討したかどうか疑問に思っています。 スクリプトのJSON出力を汚染しないように警告を抑制しなければなりません（または何かが足りないのですか？）

@macterra理解できません。 警告を無効にするための代替戦略をお探しですか...？

また、Webhookが証明書の検証を無効にしている理由も非常にわかりません。 そのままにしておきたいと思います。

さらに、結果を得るためにスクリプトからstdoutをパイプ処理している場合、警告がstderrから出力されるため、JSON出力を汚染しないようにする必要があります。

そうです、警告がstderrにある場合は、問題ありません。 コンソールの出力を見てもわかりませんでした。間違いです。

urllib3のドキュメントではなく、リクエストのドキュメントを指すようにこれをカスタマイズする必要があると思います。

この警告機能が何を達成することを意味し、警告がどのように制御されることを意味するのか理解できません。

requestsを使用するモジュールがあり、 verify=False引数を使用してリクエストを行う必要があります。 これにより、モジュールのユーザーに不要な警告が表示されます。 不必要な警告は重要な警告をより見にくくします、

私のモジュールが警告を無効にすることは理にかなっていますが、アプリケーションでrequestsを使用して、他のモジュールでも警告を無効にします。

モジュールのユーザーに警告を無効にするように指示する必要がある場合、状況は良くありません。 requestsを使用しているという事実は、通常、ユーザーが知る必要のない目に見えない実装の詳細です。 そして、ユーザーはまだすべてを沈黙させるか、注意するオプションしかありません。

グローバルな警告は役に立たないと思います。

私は、サブクラス可能性がurllib3.HTTPSConnectionPoolして上書き_validate_conn()とmake requests他のモジュールから避け隠蔽の警告に私のモジュールでの使用が、それは単純なことのためにあまりにも多くの仕事のようです。

この警告機能が何を達成するのか理解できません

モジュールのユーザーに不要な警告が表示されます。

verify=Falseを設定すると、ネットワーク接続が保護されなくなります。 それは、私見ですが、不必要な警告ではなく、非常に関連性の高い警告です。 以前は証明書を検証していないことを知らなかったユーザーは、これが真実であることを知っています。

警告がモジュールにとって価値がない場合、アプリケーション内の他のモジュールにとって価値がない可能性があります（1つのネットワークポイントでセキュリティを破棄すると、他の場所でそれについて叫ぶ意味はありません）。 グローバルに無効にしても問題はありません。

ユーザーが特定のリクエストに対して明示的にverify=Falseをリクエストした場合、警告を表示することの価値がわかりません。 モジュールの作成者としてverify=Falseを設定するときは、ユーザーの要求に応じて設定します（または、悪意を持っていますが、警告を消すことができるため、警告も役に立ちません）。 確かに、私は悪意のあることを避けたいし、警告をグローバルに沈黙させたくない。なぜなら、それはアプリケーションの他の部分が無意識のうちに安全でないことをしているそれらの要求に対する有用な警告を取り除くからだ。

また、ユーザーが検証を明示的にオフにしているリクエストに対して警告をオンにすると、警告が1回だけ与えられるため、ユーザーが警告を必要とするリクエストも非表示になります。 警告は、特定のリクエストのURLに言及していないため、ユーザーにとってもあまり役に立ちません。

1つのネットワークポイントでセキュリティを破棄すると、アプリケーションでセキュリティチェックが役に立たなくなることに同意しません。また、ブラウザベンダーも同様です。 ブラウザを使用すると、個々のURLのセキュリティチェックをバイパスできますが、残りのURLは引き続きチェックするので、気に入っています。

内部ネットワーク内の自己署名証明書を使用して内部サーバーと通信するだけでなく、外部ホストとも通信するツールがある場合、外部通信を確認したいと思います。 これは、ユーザーとして、誤って保護されていないリクエストに関する警告を表示したい状況です。

私がservice_foo 、誰かがそれをアプリで使用していると考えてください。

import service_foo
import requests

session = service_foo.Session('https://10.0.0.1', verify=False)
data = session.get_data()
requests.put('https://example.com/submit', data=data)

service_fooには2つのオプションがあります：

1. グローバルセキュリティ警告をオンにします
   
   
   
   • アプリケーションがhttps://10.0.0.1通信すると、ユーザーは常に警告を受け取ります
   
   
   • https://example.com/submitへのリクエストが安全でなくても、ユーザーに警告が表示されることはありません
   
   
2. グローバルセキュリティ警告をオフにします。
   
   
   
   • https://example.com/submitへのリクエストが安全でなくても、ユーザーに警告が表示されることはありません
   
   

どちらのオプションも良いとは思いませんが、オプション1は誤警報を発しているため、より悪いです。 しかし、モジュールを使用した場合の副作用として、ユーザーのセキュリティチェックをオフにするのは気が進まない。

シェルスクリプトを使用してこれを行うと、ユーザーはより幸せで安全になります。

curl --insecure -o data https://10.0.0.1/get_data
curl --upload-file data https://example.com/submit

私にとっては、Pythonプラットフォームの構成が壊れている場合にのみ警告を出すのが理にかなっています。 InsecureRequestWarningメッセージでリンクされているhttps://urllib3.readthedocs.org/en/latest/security.htmlページは、プラットフォームの問題を修正する方法を示すことを目的としています。 ユーザーが検証のスキップを要求した場合、ユーザーがhttpsではなくhttp URLを要求した場合に警告が表示されないように、警告が表示されないようにする必要があります。

ユーザーが特定のリクエストに対して明示的にverify = Falseをリクエストした場合、警告を表示することの価値はわかりません。

「ユーザー」は誰ですか？ あなたが2人の聴衆を混乱させていると私は信じているので、あなたの投稿を通して、この質問は私の頭に浮かび続けました。

モジュールの作成者としてverify = Falseを設定した場合、ユーザーの要求によって設定します（または悪意を持っています）。

またはあなたは怠慢です。 自己署名証明書と相互運用できないというユーザーからの苦情があったため、証明書の検証をオフにすることはその問題に対処する方法ではないにもかかわらず、証明書の検証をオフにしました。

これにより、アプリケーションの他の部分が無意識のうちに安全でない要求を行っている場合に、これらの要求に対する有用な警告が削除されます。

この文は私を困惑させます。 これは、アプリケーションが_無意識のうちに_安全でない要求を行ったときに警告することは許容できるが、アプリケーションが_知っているように_要求を行っても問題がないことを示唆しています。 安全でないリクエストを故意に行うことは、無意識のうちにそうすることよりも「より安全」であるとどのように見なされるべきかわかりません。

また、ユーザーによって検証が明示的にオフにされているリクエストに対して警告をオンにする

どのユーザーですか？ モジュールの作成者と「ユーザー」をどのように区別しますか？

警告は、特定のリクエストのURLに言及していないため、ユーザーにとってもあまり役に立ちません。

警告スパムを生成するリスクがあるため、警告にはリクエストのURLを記載しないでください。 「この特定の通信が危険にさらされている」ではなく、「このアプリケーションが危険にさらされている」と_一度_警告します。

ブラウザを使用すると、個々のURLのセキュリティチェックをバイパスできますが、残りのURLは引き続きチェックするので、気に入っています。

無効な証明書を使用してURLにアクセスすると、ブラウザベンダーは_警告_します。 ダイアログボックスを印刷し、URLバーを赤で強調表示します。 それが私たちがしていることです。 私たちはあなたが何かをするのを止めているのではなく、ただ「ねえ、これは悪い！」と言っているだけです。 あなたが私たちに求めていることは、ユーザーが特定のURLに対してその赤い警告をオフにすることを許可するようにブラウザベンダーに求めることと同じであり、セキュリティへの影響が非常に大きいため、そうすることを拒否することを保証します。

内部ネットワーク内の自己署名証明書を使用して内部サーバーと通信するだけでなく、外部ホストとも通信するツールがある場合、外部通信を確認したいと思います。

いいえ、通信をすべて確認する必要があります。 自己署名証明書を確認してください！ 取得する予定の証明書を取得したことを確認します。 verify=Falseは、セキュリティに対する大ハンマーのアプローチと見なす必要があります。事実上、「セキュリティをねじ込み、機能させるだけです」と言っています。 それは絶対に問題ありません、あなたにはそれを言う権利があります、しかし私達はそれを安全でないと呼ぶ義務があります。

どちらのオプションも良いとは思いませんが、オプション1は誤警報を発しているため、より悪いです。

オプション1は誤ったアラームを発するのではなく、実際のアラームを発します。 10.0.0.1への通信は_安全でない_ので、他のふりをしてはいけません。

シェルスクリプトを使用してこれを行うと、ユーザーはより幸せで安全になります。

ユーザーはもっと幸せかもしれませんが、安全ではありません。 以前とまったく同じように安全です。 この警告をオフにすると、魔法のように証明書の検証が無効になるという印象を受けているようですが、そうではありません。 この応答の最後で、これについてもう一度触れます。

私にとっては、Pythonプラットフォームの構成が壊れている場合にのみ警告を出すのが理にかなっています。

いいえ、Pythonプラットフォームの構成が壊れていて、未確認のリクエストを要求しなかった場合は、大失敗するはずです。 プラットフォームが安全なTLS接続を確立できない場合は、ユーザーが（ verify=False設定して）気にしないように明示的に指示した場合を除いて、絶対に接続しないでください。やろうとしているのは危険です。

あなたは誤解の下で働いていると思うので、私は何かを非常に明確にしたいと思います：a） verify=False （私たちの警告行動）を設定するか、またはb） sslモジュールを故意に妨害する。 b）を捕まえることはできず、警告もしません。 これは、あなたが提起した「プラットフォームの問題」の概念に該当する唯一の状況です。 urllib3のヘルプページのアドバイスは、信頼できる証明書のバンドルや手動での証明書の検証など、プラットフォームに関連する必要なすべての手順を実行するため、適用されません。

Webコミュニティには、信頼されたルート証明書によって署名された証明書のみを検証する必要があるという危険な見方があります。 この見方は完全に見当違いです。 自己署名証明書に遭遇した場合は、それらを十分に検証する必要があります。 それは完全に実行可能です！ 自己署名証明書を.pemファイルに追加し、引数としてverify渡します。

バンドルされている.pemファイルとの組み合わせで問題が発生した場合は、お知らせください。mkcert.orgを拡張して、独自の証明書を信頼できるルートと連結できるようにします。 ただし、 verify=Falseが安全であると偽ってはいけません。単に安全ではありません。

また、ユーザーが検証を明示的にオフにしているリクエストに対して警告をオンにすると、警告が1回だけ与えられるため、ユーザーが警告を必要とするリクエストも非表示になります。

これも少し困惑します。 verify=Falseを設定することで、そのリクエストに対して明示的にオフにすることもできますが、リクエストを作成するポイントを超えてそれを伝える方法はありません。 また、証明書の検証を無効にしているため、それを超えて伝達する理由はありません。 あなたがそうした文脈は、私たちやあなたのアプリを使用している人には何の影響もありません。

あなたが私たちに求めていることは、ユーザーが特定のURLに対してその赤い警告をオフにすることを許可するようにブラウザベンダーに求めることと同じであり、セキュリティへの影響が非常に大きいため、そうすることを拒否することを保証します。

私のブラウザでは、「非常に安全でない」未確認の証明書を永続的に受け入れることができます。

10.0.0.1への通信は安全ではないため、他のふりをしてはなりません。

接続は、デジタル証明書を検証できないという点で安全ではありませんが、証明書を検証しても、通信しているサーバーが安全であるかどうかは実際にはわかりません。 しかし、閉じたネットワーク内のサーバーと話しているときは、サーバーのセキュリティを本当に確認できます。

あなたは誤解の下で働いていると思うので、私は何かを非常に明確にしたいと思います：a）verify = False（警告動作）を設定するか、b）意図的に設定せずにリクエストで未検証のHTTPSリクエストを行う方法はありませんSSLを妨害する

私は、ユーザーが私に与えたURLの証明書チェックと警告を無視したいというユーザーの希望を尊重することによって、モジュール内でどのようにして善良な市民になることができるのか疑問に思っています。 そして、警告モデルが追加する価値。 verify=Falseを含むリクエストで、ユーザーに警告が表示される場合はどうなりますか？

警告メカニズムが怠慢なコードをどのようにキャッチできるかわかりません。なぜなら、コーディングがずさんなためにリクエストが行われたのか、ユーザーがリクエストしたためにリクエストが行われたのかを区別できないからです。 requestsようなモジュールもセキュリティポリシーを指示するべきではないと思います。 警告は通常、開発者が誤ったコードを修正できるようにすることを目的としていることを理解しましたが、この警告はそのようなものではありません。 警告がユーザーの一般的な教育のためだけのものである場合、ユーザーがそれを隠すための簡単な方法があるはずです。

警告を受け取ることは、プログラムの出力を台無しにするので、見た目だけではありません。

警告の負の値しか表示されないので、そのようなグローバルポリシーの変更をそこで非表示にするのが嫌いな場合でも、モジュールで警告をオフにします。

Webコミュニティには、信頼されたルート証明書によって署名された証明書のみを検証する必要があるという危険な見方があります。 この見方は完全に見当違いです。

そのような見方があることを知りませんでした。 ルート証明書によって署名された証明書は、サイトのセキュリティについて実際には何も証明しません。 悪いことをしたいのなら、匿名の証明書を取得するのは安いです。

自己署名証明書に遭遇した場合は、それらを十分に検証する必要があります。 それは完全に実行可能です！ 自己署名証明書を.pemファイルに追加し、それを引数として渡して検証します。

ユーザーは、内部の信頼できるネットワークのように、証明書を取得するための安全なチャネルが必要になります。 ただし、サーバー自体が同じ内部ネットワーク内にある場合は、あまりメリットがありません。 しかし、これはいずれにせよユーザーが決定するものであり、モジュールにポリシーを課すことはできません。

ほとんどの場合、 @ kankriに同意します。 それが本来の設計意図でした。

私は何かを提案します—デフォルトで無効にしますが、それを再度有効にする、またはそれをオンにする方法を文書化するための独自の機能を持っています。 意図したとおりにコードを使用するために、ユーザーが邪魔にならないようにしたいのです。 verify=Falseは機能ですが、ベストプラクティスではありません。 それは私たちの仕事ではありません。

verify=Falseが機能であることに同意しますが、 params=またはcert=と同じレベルの機能であることに同意しません。 これはデフォルトで安全な値に設定され、安全でない値に設定される可能性がある機能です。 便宜のためにセキュリティを窓の外に投げ出すことは、人々にとって巨大で魅力的なオプションであり、衝動に抵抗する必要があると思います（ただし、禁止されるべきではありません）。 私は常に「あなたは明らかに不安であるに違いない」という考え方に傾倒します。それが1つではなく2つのスイッチをフリックすることを意味するかどうかは気にしません。

とにかく、これは私のものではなくあなたの呼びかけです。 =）

@kankriと@kennethreitzの発言に同意します

verify = Falseは機能ですが、ベストプラクティスの機能ではありません。 それは私たちの仕事ではありません。

それをうまくまとめます。

警告を無効にしたい人のために、これはそれを行う方法です。 標準ライブラリの一部である警告モジュールを使用する必要があります。

import warnings
import requests
from requests.packages.urllib3 import exceptions

with warnings.catch_warnings():
    warnings.simplefilter("ignore", exceptions.InsecureRequestWarning)
    warnings.warn('a non-requests warning is not blocked')
    print requests.get('https://rsa-md5.ssl.hboeck.de/', verify=False)

これにより、カテゴリInsecureRequestWarning警告を無視する警告フィルタが構成されます。 出力は次のようになります。

test.py:46: UserWarning: a non-requests warning
  warnings.warn('a non-requests warning is not blocked')
<Response [403]>

（テストサイトはたまたま403 Forbiddenページを返しますが、ここでは重要ではありません。）

バンドルされているurllib3パッケージのクラスを使用する必要があり、トップレベルのurllib3パッケージがインストールされている場合は、そのクラスを使用しないことに注意してください。

コードの可能な限り最小の領域でコンテキストマネージャーを使用する小さな関数を作成できます（おそらくそうすべきです）。

def silent_unverified_get(*args, **kwargs):
    kwargs['verify'] = False
    with warnings.catch_warnings():
        warnings.simplefilter("ignore", exceptions.InsecureRequestWarning)
        return requests.get(*args, **kwargs)

または単にこれを行います：

requests.packages.urllib3.disable_warnings()

@ルカサ

または単にこれを行います：

requests.packages.urllib3.disable_warnings()

リクエストマニュアルにこの機能についての言及がないことを除いて。

それを知っている人からはほど遠いですが、 warningsモジュールは、Pythonプログラマーが警告を無効にしたいときに注目すべき標準ツールであると私は主張します。 これは標準ライブラリの一部であり、十分に文書化されています。

warningsへのrequestsドキュメントに入れることをお勧めします。または、対応するenable_warningsがある限り、必要に応じて便利なdisable_warnings関数への参照を入れることをお勧めします。関数（そのような関数はないようです）。

繰り返しますが、一般的に警告を無効にしたくありません。 コードでverify = Falseを_明示的に_設定したときに、この特定の警告を消したいだけです。 この特定の役に立たない警告とは異なり、他の有用な警告があるかもしれません。 これについて理解するのがとても難しいのは何ですか？！

@zaitcev自分自身を繰り返すリスクがあります：

requests.packages.urllib3.disable_warnings()

そして、それでもあなたにとって広すぎる場合：

from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

最後に、 @ zaitcevに注意してください。今行ったばかりの憤慨した口調を何の恩恵も受けられないことがわかります。 私たちはすべてボランティアであり、あなたに物を作るために与える時間は限られていることを忘れないでください。 あなたが扱いたい方法で私たちを扱ってみてください。

@zaitcevこれはrequestsモジュール自体では変更されないようですが、他のコメントに入力したコードを使用できることを願っています。 これにより、urllib3によって発行される警告を選択的に無効にできるはずです。

次の方法で抑制することもできます。

with warnings.catch_warnings():
  warnings.filterwarnings("ignore", message=".*InsecurePlatformWarning.*")
  ...

私の場合、リクエストを直接使用していないので、このように抑制することで、後で壊れることを少し心配する必要がなくなります。

@zaitcevこれまでのすべての提案をまとめると、次のようなことができます。

verify = False
if not verify:
    from requests.packages.urllib3.exceptions import InsecureRequestWarning
    requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
r = requests.get('https://www.example.com', verify=verify)

@utkonosこれにより、後続のすべてのリクエストに対して警告が無効のままになります。

他の例をまとめて、デフォルトのSessionを拡張しました（とにかく、 requests.getと他のショートカットが一時的なSession作成するため）：

from requests.packages.urllib3 import exceptions

class Session(requests.sessions.Session):

    def request(self, *args, **kwargs):
        if not kwargs.get('verify', self.verify):
            with warnings.catch_warnings():
                warnings.simplefilter('ignore', exceptions.InsecurePlatformWarning)
                warnings.simplefilter('ignore', exceptions.InsecureRequestWarning)
                return super(Session, self).request(*args, **kwargs)
        else:
            return super(Session, self).request(*args, **kwargs)

requestsからのすべての警告を無効にすることは、おそらく悪い考えです。もう少し良いかもしれません：

import requests
from requests.packages.urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

私がこれをどのように処理したかを要約すると：

import warnings
with warnings.catch_warnings():
    warnings.simplefilter("error") 
    try:
        req = requests.get("https://an-insecure-server.com")
    except (RuntimeWarning, requests.exceptions.SSLError)::
        log.error("Making an insecure request")
        warnings.simplefilter("ignore")
        req = requests.get("https://an-insecure-server.com")

これにより、リクエストが安全でないかどうかを確認し、urllib警告を非表示にして、ユーザーに対して独自のフォーマットの警告を出すことができます。 リクエストは2回行う必要があります。 除外句の幅を狭めるように編集されました。

except Exception:は非常に広いです。 あなたは本当にそれを望んでいません。

上記は、この議論の両側の懸念に対処するための何らかの方法になります。

代わりにキャッチできるExceptionのサブクラスをスローしませんか？

またはlogging.captureWarnings()使用します

別の方法は、urllib3が関係していることを知り、その名前空間をハードコーディングすることです。tuukkamustonenによるコメントを参照してください。 これが私の主な反対意見でした。彼らはそれを正しく機能させることができたでしょう、私はプルリクエストでパッチを提供することさえしました。 しかし、彼らは問題が存在することを否定し、すべてのユーザーに「例外を除いて」や「requests.packages.urllib3インポート例外から」のようなひどい回避策を考え出すように言います。 この時点で、誰かが彼らがずっと間違っていたことを認めなければならないので、私たちは立ち往生しています。

これが私の主な反対意見でした。彼らはそれを正しく機能させることができたでしょう、私はプルリクエストでパッチを提供することさえしました。 しかし、彼らは問題が存在することを否定し、すべてのユーザーに「例外を除いて」や「requests.packages.urllib3インポート例外から」のようなひどい回避策を考え出すように言います。 この時点で、誰かが彼らがずっと間違っていたことを認めなければならないので、私たちは立ち往生しています。

@zaitcev繰り返しになりますが、これはできる限り最善を尽くしているボランティアコミュニティであることを思い出させてください。 私たちはこの問題を議論のために自由に残しました、私たちはそれをロックしたり、さらなる議論を妨げようとはしませんでした。 私たちは_あなたに耳を傾けています_。 私たちが行っていないのは、状況の評価にすぐに同意することです。 単なるユースケースよりも多くのユースケースに関心があり、それらすべてのニーズのバランスを取る必要がある可能性を考慮してください。

あなたのプルリクエストに関しては、あなたが常に無視している_非常に特定の理由_のために拒否されました！ イアンを引用して自分自身を引用させてください：

締めくくりの声明は次のとおりでした。「これはほとんどurllib3にあり、そこでの受け入れに依存するので、そこで進展が見られるまでこれを閉じます。 」（強調鉱山）

今日の時点で、urllib3にこの問題に関連するプルリクエストまたは問題はまだ表示されていません。 このプロジェクトの誰もあなたの邪魔をしたり、この作業の発生を妨げたりしていません。_現在あなたに同意していない_ため、私たちは自分たちでそれを行うことを選択していません。

ただし、このうさぎの穴を再び下るリスクがあるので、繰り返します。

これが私の主な反対意見でした。彼らはそれを正しく機能させることができたはずです。

私はあなたのパッチがこの仕事を「正しく」することを信じていません。 このスレッドで何度も言ったように、現在の動作は望ましいと思います。 安全でないTLS要求を行うことは悪い考えであり、ユーザーはそうしないように警告されるべきです。

私の立場では、特にパスワードを処理しているシステムでは、ユーザーが適切に保護されていないTLS要求を行っているときに_知る価値があります_。

このスレッドには、これらの警告を無効にするためのリクエストレベルのフックを検討する必要があるというverify=Falseとverify=None間に以前は存在しなかった区別を追加する必要があると考えています。 前者の方が後者よりもはるかに簡単であることがわかります。

verify = Falseとverify = Noneを区別しないように+1します。 私はどちらかをサポートします：

• 新しいパラメータ（たとえば、noInsecureWarnings）を追加する、または
• リクエストでurllib3警告をインターセプトし、独自の警告を発行するので、（a）「requests.packages.urllib3.exceptions.InsecureRequestWarning」（とにかくすでにリクエスト固有ですが、リクエストが移行すると壊れます）よりも怖くないものを抑制することができます（b）警告はリクエスト固有のURLを指すことができます（警告がシェーディングされているため、現在のURLは関係ありません！）

そして、これが修正されるかどうかにかかわらず、リクエストをサポートしてくれたすべてのボランティアに感謝します：それは素晴らしいライブラリです:)

これは素晴らしいライブラリです、あなたのすべての努力に感謝します。

最近Pythonパッケージをアップグレードし、多数の新しいInsecurePlatformWarningプリントアウトに気付いた後、この問題に遭遇しました。 ですから、私は自分のユースケースに貢献しています。これは説得力があると思います。

リクエストを使用して、4つの異なる環境でjenkinsサーバーを管理しています。 3つの環境（開発、ステージング、本番）にはすべて有効な証明書があります。 4番目の環境は、開発者がローカルマシンで変更をテストするために使用できるvagrant仮想ボックスです。 これには有効な証明書がありませんが、ポリシーの問題として、すべてのサーバー構成が暗号化されていない要求を拒否します。

環境のjenkins接続設定（サーバー名、トークンなど）には、SSL検証をオフにするための特定のフラグが含まれています。これはvagrant環境ではTrueにのみ設定されます。

私の設定では、プロジェクトがかなり大きく、リクエストライブラリの有無にかかわらず、多くのリクエストが行われる可能性があるため、警告をグローバルに無効にすることはお勧めできません。 プロジェクトの一部にフラスコアプリケーションやその他のマルチスレッドのケースが含まれている場合を除いて、スコープ内の警告を無効にしても問題ありません。

私の意見では、verify = Falseの使用はサポートされ、警告なしで期待どおりに機能するはずです。 これをいつ許可するか、許可するかどうかは、アプリケーション開発者が決定します。 たとえば、一般的な使用のためにブラウザを作成している場合、赤いテキストがたくさんある大きな確認ダイアログを表示せずに、これをTrueに設定することは決してありません。 しかし、私がサーバーとクライアントを所有していて、証明書を発行しないという独自の理由がある場合は、クリーンなログを作成し、他の潜在的な問題を隠さないようにする必要があります。

これをいつ許可するか、許可するかどうかは、アプリケーション開発者が決定します。

この論争は私があなたと違うところです。 いつ使用するかは開発者次第だと思います。 しかし、その選択が受け入れられるかどうかを判断するのは_user_次第だと思います。 ユーザーが開発者の選択によってリスクにさらされていることを理解し、そのリスクを評価できることは_重要_です。

しかし、私がサーバーとクライアントを所有していて、証明書を発行しないという独自の理由がある場合は、クリーンなログを作成し、他の潜在的な問題を隠さないようにする必要があります。

そして、ロギングコンテキストマネージャーを使用して警告をキャプチャすることで、これを行うことができます。 また、リクエストでこの警告をリクエストに固有のものにして、キャプチャしやすくすることも検討していますが、まだ発生していません。

@ jamie-sparkedに似た状況があります。

セキュリティの強化に関するLukasaのポイントは理解していますが、ユーザーに最適なものを決定させる必要があると思います。
Requestsはライブラリであり、エンドユーザーアプリケーションではありません。 IMOでは、開発者をユーザーと見なす必要があります。
アプリケーション開発者は、証明書の検証をオフにすることを決定した場合（つまり、verify = False）、セキュリティの間違いについて責任を負う必要があります。

開発者として、私は自分が何をすべきかを指示しようとするライブラリよりも柔軟性を重視しています。

ところで、他の人が言ったように、私はリクエストが_素晴らしい_と思います、そして私はあなたのすべての努力に感謝します。 ありがとう。

@thalesac開発者に決定を任せます。 このスレッドで何度も説明されているように、この警告をオフにすることはかなり可能です。 ただし、すべての警告をオフにするスイッチは1つではありません。手動で、それぞれを行う必要があります。 これは、ユーザーに各安全ガードを_意識的に_削除させる試みです。

多層防御と考えてください。 フットガンの例えを使用するために、安全装置がオンで弾丸が入っていない銃とマガジンをお渡しします。 verify=Falseすべての警告を無効にした場合、それは、マガジンが挿入されたときに自動的に安全を無効にしてラウンドをチャンバーする銃を持っているのと同じです。 便利？ もちろん。 危険？ あなたは賭けます。

恐れ入りますが、あなたのアナロジーモデルには同意しません。
verify = Falseはあなたの安全/セキュリティメカニズムだと思います。 明示的に（または手動で）無効にした場合、悪者を撃っているときに銃が常に警告を発することは望ましくありません。 明らかに、デフォルトの動作はセキュリティの考え方を強制する必要があります。
とにかく、これは私の見解であり、プロジェクトに最適だと思うことを実行する必要があることを理解しています。 たぶんそれが良いライブラリである理由です。 :)
ありがとう

私はLukasaに間違いなく同意します。最初のセキュリティです。開発者として、コードの一部でverify = Falseを使用している場合、警告を表示したくない場合は、警告を非表示にする必要があります。

とにかく、あなたのチームワークの優れたライブラリの大ファン、それを維持し、忍耐が私たちに応答するために+10000。

私の見方では、アプリケーションがユーザーによって設定されたURLを使用している場合、ユーザーには検証を無効にするオプションを提供する必要がありますが、どのような状況でも警告が表示されるはずです。 開発者として、有効な証明書を持っているとは思われないURLに接続していることが何らかの理由でわかっている場合（証明書の支払いを行わない内部サービス、テストなど）、無効にするオプションが必要です。検証を無効にするとともに警告。

同時に、警告をグローバルに一度に無効にしたい状況が発生することは一般的ではないと思います。そうすると、黙って無視されるセキュリティの問題が簡単に発生するためです。

requests.packages.urllib3.disable_warnings()はいそれは仕事です

やあ

requests.packages.urllib3.disable_warnings()はもう機能していませんか？ それは私のために警告を沈黙させていました。 ここで、警告の無効化関数を呼び出しています。警告関数が呼び出されるバックトレースの例を次に示します。

 [+] https://drupal.org/へのリダイレクトを受け入れました
 > /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py（791）_validate_conn（）
 -> warnings.warn（（
 （Pdb）bt
 / root / droopescan / droopescan（5）（）
 -> droopescan.main（）
 /root/droopescan/dscan/droopescan.py（55）main（）
 -> ds.run（）
 /usr/local/lib/python2.7/dist-packages/cement/core/foundation.py（764）run（）
 -> self.controller._dispatch（）
 /usr/local/lib/python2.7/dist-packages/cement/core/controller.py（466）_dispatch（）
 -> func（）を返す
 /usr/local/lib/python2.7/dist-packages/cement/core/controller.py（472）_dispatch（）
 -> func（）を返す
 /root/droopescan/dscan/plugins/internal/scan.py（114）default（）
 -> follow_redirects）
 /root/droopescan/dscan/plugins/internal/scan.py（230）_process_cms_identify（）
 -> if inst.cms_identify（url、opts ['timeout']、self._generate_headers（host_header））== True：
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py（910）cms_identify（）
 ->ヘッダー）
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py（827）enumerate_file_hash（）
 -> r = self.session.get（url + file_url、timeout = timeout、headers = headers）
 /usr/lib/python2.7/dist-packages/requests/sessions.py（480）get（）
 -> return self.request（ 'GET'、url、** kwargs）
 /usr/lib/python2.7/dist-packages/requests/sessions.py（468）request（）
 -> resp = self.send（prep、** send_kwargs）
 /usr/lib/python2.7/dist-packages/requests/sessions.py（576）send（）
 -> r = adapter.send（request、** kwargs）
 /usr/lib/python2.7/dist-packages/requests/adapters.py（376）send（）
 ->タイムアウト=タイムアウト
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py（559）urlopen（）
 -> body = body、headers = headers）
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py（345）_make_request（）
 -> self._validate_conn（conn）
 > /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py（791）_validate_conn（）
 -> warnings.warn（（

以下はpip freezeの出力です、私はdebianテストを使用しています：

 argparse == 1.2.1
 beautifulsoup4 == 4.4.1
セメント== 2.6.2
 chardet == 2.3.0
 colorama == 0.3.3
カバレッジ== 4.0.3
暗号化== 1.2.1
 distlib == 0.2.1
 -e git + git @ github.com：droope / droopescan.git @ 6524a9235e89a6fdb3ef304ee8dc4cb73eca0386＃egg = droopescan-開発
 enum34 == 1.1.2
 funcsigs == 0.4
先物== 3.0.4
 html5lib == 0.999
 httplib2 == 0.9.1
 idna == 2.0
 ipaddress == 1.0.16
 lxml == 3.5.0
水銀== 3.5.2
モック== 1.3.0
 ndg-httpsclient == 0.4.0
 nose == 1.3.7
 pbr == 1.8.1
 pyOpenSSL == 0.15.1
 pyasn1 == 0.1.9
 pycurl == 7.21.5
 pystache == 0.5.4
 python-apt == 1.1.0b1
 python-debian == 0.1.27
 python-debianbts == 2.6.0
 reportbug == 6.6.6
リクエスト== 2.9.1
応答== 0.3.0
再試行== 1.3.3
 6 == 1.10.0
 urllib3 == 1.13.1
ホイール== 0.26.0
 wsgiref == 0.1.2

ありがとう、
ペドロ

disable_warningsは、警告関数の呼び出しを妨げるものではなく、出力を抑制するだけです。 他のコードですべての警告が有効になっていると、問題が発生する可能性があります。

こんにちは@Lukasa 、

ifの後にブレークポイントを置きます。 結局、私はあまりにも多くの問題に遭遇したので、debianテストの使用をやめました、そしてこれはそれらの1つである可能性が非常に高いです。 私は自分のコメントを無視します。何が起こったのかはわかりませんが、多くの人に影響を与えるものではない可能性があります。

ありがとう！
ペドル

ええ、あなたがdebianのパッケージを使っていたのなら、彼らのベンダーのないロジックがここで何かを壊した可能性があります。

verify=Falseを指定して安全でない要求を行い、他の場所で行われた他の要求の警告に干渉することなく、その要求の警告を表示したくない場合は、完全に合理的と思われます。

from requests.packages.urllib3.exceptions import InsecureRequestWarning

...
with warnings.catch_warnings():
    warnings.filterwarnings("ignore", category=InsecureRequestWarning)
    resp = requests.get(url, verify=False)  # InsecureRequestWarning suppressed for this request

resp = requests.get(url, verify=False)  # InsecureRequestWarning not suppressed for this request
...