Requests: verify=False 和 requests.packages.urllib3.disable_warnings()

我认为您可以使用warnings模块在全局级别禁用这些。 此外，要使用日志记录（如果我没记错的话），您需要访问urllib3 （并且我们将其记录在案），因此我不反对为不打算对 HTTPS 使用证书验证的用户记录此内容连接。

我仍然强烈支持保留这些警告。 是的，它们很烦人，但它们存在也是有原因的。 如果有的话，我很想关闭它并用我们自己的一个替换它！ =P

在这一点上，很明显@Lukasa和我在此功能上的@kennethreitz @shazow 有什么意见吗？

在某种程度上，我同意警告很重要，但我认为可能需要考虑多种因素。

从开发人员的角度来看，知道我知道这一点，如果我愿意，我可以关闭它。 我对软件包比较新，所以当我阅读文档时，在警告中，该解决方案实际上不起作用。 我喜欢@Lukasa提出的关于制作特定于requests东西的想法。

从用户的角度来看，我今天安装了pyvmomi和pip ，它在其内部使用了requests 。 在requests是一个无声的支持库的情况下，这确实是一个不透明的错误，它会被发送回用户。

是的， requests.packages.urllib3.disable_warnings()是使用警告模块过滤将其关闭的快捷方式。

我强烈建议对此效果发出某种警告。 +0.5 传播 urllib3，+1 如果你想付出努力并添加一个特定于请求的请求。 -1 没有警告。

如果您愿意，我们可以使 urllib3 警告消息可配置，您可以覆盖它，以便您可以搭载相同的逻辑。

再一次，我不认为这条消息对用户有敌意，我认为它非常有价值。 您现在知道pyvmomi关闭了TLS证书验证，这是相当重要的信息！

也就是说，我不反对我们有更多的请求方式来使其静音。

是的，我真的认为这是pyvmomi一个错误。 如果他们不想像这样尴尬，他们应该在他们的工具中禁用警告。 _不_警告用户某些工具建立的连接可能使他们遭受 MITM 攻击，这不是我们的工作，因为该工具不执行证书验证。

谢谢大家的讨论！ 我非常感谢每个人的评论，并帮助我看到做事方式的价值，以及为什么。 我很难看到更一般的情况！ :)

今天将在补丁上工作，如果时间允许，有一种“请求-y”的方式来静音。 欢迎反馈！

@invisiblethreat如果您有任何疑问，请随时加入 IRC

只是想知道您是否考虑过在 webhook 中使用请求的情况。 我必须取消警告，这样它就不会污染脚本的 JSON 输出（或者我错过了什么？）

@macterra我不确定我是否理解。 您是否正在寻找禁用警告或...的替代策略？

我也非常不清楚为什么您的 webhook 禁用证书验证。 我想把它留在上面。

此外，如果您从某个脚本通过管道传输 stdout 以获取结果，则会从 stderr 发出警告，因此它们不应污染您的 JSON 输出。

是的，如果警告在 stderr 上，那就没问题了。 我无法通过查看控制台中的输出来判断，我的错误。

我认为我们应该自定义它以指向请求文档而不是 urllib3 的文档。

我不确定我是否理解此警告功能的目的以及如何控制警告。

我有一个使用requests的模块，并且必须使用verify=False参数发出请求。 这会导致我的模块的用户看到不必要的警告。 不必要的警告使重要警告更难看到，

我的模块禁用警告是有意义的，但是_我也会在任何其他模块中禁用警告_在应用程序中使用requests ！

如果我需要指示我的模块的用户禁用警告，情况并没有好转：我使用requests的事实通常只是用户不需要知道的不可见的实现细节。 并且用户仍然只能选择将所有内容静音或注意。

我认为全球警告不会有帮助。

我可以子类化urllib3.HTTPSConnectionPool并覆盖_validate_conn()并使requests在我的模块中使用它以避免隐藏来自其他模块的警告，但这对于一件简单的事情来说似乎太多了.

我不确定我是否理解此警告功能的目的

导致我的模块的用户看到不必要的警告。

当您设置verify=False您将不再保护您的网络连接。 恕我直言，这_不是_一个不必要的警告，这是一个非常相关的警告。 您的用户以前不知道您没有验证证书，现在知道这是真的。

如果警告对您的模块没有价值，那么它对应用程序中的任何其他模块都没有价值（一旦您在一个网络点上放弃了安全性，就没有必要在其他任何地方吹嘘它）。 我真的没有看到全局禁用它的问题。

当用户为特定请求明确请求verify=False ，我看不到显示警告的价值。 当我作为模块作者设置verify=False ，我根据用户的请求设置它（或者我是恶意的，但警告也无济于事，因为我可以使警告静音）。 事实上，我想避免恶意并且不想全局静音警告，因为这消除了应用程序的其他部分在不知不觉中不安全地发出的那些请求的有用警告。

此外，为那些用户明确关闭验证的请求打开警告也会隐藏用户想要警告的请求，因为警告只发出一次。 该警告对用户也没有真正的帮助，因为它没有提到特定请求的 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两个选项：

1. 我保持全球安全警告
   
   
   
   • 当应用程序与https://10.0.0.1对话时，用户总是会收到警告
   
   
   • 即使对https://example.com/submit请求不安全，用户也不会收到警告
   
   
2. 关闭全局安全警告：
   
   
   
   • 即使对https://example.com/submit请求不安全，用户也不会收到警告
   
   

我认为这两个选项都不好，但选项 1 更糟，因为它会发出错误警报。 但是我不习惯为用户关闭安全检查作为使用我的模块的副作用。

如果我用 shell 脚本来做这件事，用户会更快乐、更安全：

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确实旨在展示如何解决平台中的问题。 如果用户请求跳过验证，则不应出现警告，例如如果用户请求http URL 而不是https URL，则不会出现警告。

当用户为特定请求明确请求 verify=False 时，我看不到显示警告的价值。

谁是“用户”？ 在您的整个帖子中，这个问题一直在我脑海中浮现，因为我相信您将两个观众混为一谈。

当我作为模块作者设置 verify=False 时，我是根据用户的请求设置的（或者我是恶意的）。

或者你疏忽了。 您曾让用户抱怨他们无法与他们的自签名证书互操作，因此您关闭了证书验证，尽管关闭证书验证_不是_处理该问题的方法。

这消除了那些请求的有用警告应用程序的某些其他部分在不知不觉中变得不安全

这句话让我摸不着头脑。 它表明当应用程序_未知地_发出不安全请求时发出警告是可以接受的，但应用程序_知道地_发出它们在某种程度上是可以的。 我不明白故意提出不安全的请求应该以任何方式被认为比不知情的情况下“更安全”。

此外，对于那些验证被用户明确关闭的请求打开警告

哪个用户？ 我们如何区分模块作者和“用户”，无论他们是谁？

该警告对用户也没有真正的帮助，因为它没有提到特定请求的 URL。

警告不应提及请求的 URL，因为这可能会产生警告垃圾邮件。 我们警告_一次_，说“此应用程序存在风险”，而不是“此特定通信存在风险”。

浏览器让我绕过对单个 URL 的安全检查，但继续检查其余部分，我喜欢这样。

当您访问带有无效证书的 URL 时，浏览器供应商会_警告_！ 他们打印对话框并以红色突出显示 URL 栏！ 这正是我们正在做的。 我们不会阻止您做任何事情，我们只是说“嘿，这很糟糕！” 您要求我们做的事情与要求浏览器供应商允许用户关闭特定 URL 的红色警告相同，我保证他们会拒绝这样做，因为安全隐患是可怕的。

当我有一个工具与内部网络中带有自签名证书的内部服务器通信，但也与外部主机通信时，我确实想验证外部通信。

不，您要验证_所有_通信。 验证自签名证书！ 验证您是否获得了预期获得的证书。 verify=False应该被认为是一种大锤的安全方法，有效地说“螺丝安全，让它工作”。 这绝对没问题，您有权这么说，但我们有义务将其称为不安全。

我认为这两个选项都不好，但选项 1 更糟，因为它会发出错误警报。

选项 1 不是发出错误警报，而是发出真实警报。 与 10.0.0.1 的通信是 _insecure_，我们不应该假装。

如果我用 shell 脚本来做这件事，用户会更快乐和更安全。

用户可能会更快乐，但他们不会更安全。 他们会像以前一样安全。 您似乎认为关闭此警告会神奇地使证书验证消失，但事实并非如此。 我将在本回复的结尾再次谈到这一点。

对我来说，只有在 Python 平台的配置被破坏时发出警告才有意义。

不，如果 Python 平台的配置被破坏并且您没有要求未经验证的请求，我们应该很难失败。 如果您的平台无法建立安全的 TLS 连接，那么我们绝对不应该建立它们，除非我们的用户明确告诉我们不要关心（通过设置verify=False ），在这种情况下，我们应该警告您即将做的是危险的。

我认为您在误解下工作，所以我想说清楚一点：如果没有 a) 设置verify=False （我们的警告行为）或b) 故意破坏ssl模块。 我们无法捕捉到 b) 并且不会对此发出警告。 这是唯一符合您提出的“平台问题”概念的情况。 urllib3 帮助页面上的建议不适用于我们，因为我们采取了所有必要的平台相关步骤，包括捆绑可信证书和手动验证证书。

网络社区中有一个危险的观点，即您应该只验证由受信任的根证书签名的证书。 这种观点是完全错误的。 如果您遇到自签名证书，您应该好好验证它们。 这是完全可以的！ 将自签名证书添加到.pem文件并将其作为参数传递给verify ！

如果您在将其与捆绑的.pem文件结合使用时遇到问题，请告诉我，我将增强 mkcert.org 以使您能够将您自己的证书与受信任的根连接起来。 但是请不要假装设置verify=False是安全的：它根本不是。

此外，为那些用户明确关闭验证的请求打开警告也会隐藏用户想要警告的请求，因为警告只发出一次。

这也有点莫名其妙。 通过设置verify=False您可能会为该请求明确关闭它，但是除了我们构建请求的点之外，没有办法传达这一点。 也没有理由在此之后传达它，因为您已禁用证书验证。 您这样做的上下文对我们或使用您的应用程序的任何人都没有影响。

您要求我们做的事情与要求浏览器供应商允许用户关闭特定 URL 的红色警告相同，我保证他们会拒绝这样做，因为安全隐患是可怕的。

我的浏览器允许我永久接受未经验证的证书，这是“极其不安全的”。

与 10.0.0.1 的通信是不安全的，我们不应该假装不安全。

这种连接是不安全的，因为您无法验证数字证书，但验证证书并不能真正告诉您正在与之通信的服务器是否安全。 但是当我与封闭网络中的服务器交谈时，我真的可以确保服务器的安全性。

我认为您在误解中工作，所以我想说清楚一点：如果没有 a) 设置 verify=False（我们的警告行为）或 b) 故意发出请求，则无法发出未经验证的 HTTPS 请求破坏 ssl

我想知道如何通过尊重用户希望忽略证书检查和他们提供给我的 URL 的警告来成为我模块中的好公民。 以及警告模型增加了什么价值。 带有verify=False的请求应该向用户显示警告的情况是什么？

我看不到警告机制如何捕获疏忽代码，因为它无法区分请求是由于草率编码还是用户请求而发出的。 我认为像requests这样的模块也不应该规定安全策略。 我知道警告通常是针对开发人员的，因此他们可以修复不正确的代码，但此警告并非如此。 如果警告只是为了对用户进行一般教育，那么应该有一种简单的方法可以让用户隐藏它。

收到警告也不仅仅是装饰性的，因为它会弄乱程序的输出。

我只看到警告的负值，所以即使我不想在那里隐藏这样的全局策略更改，我也会在我的模块中将其关闭。

网络社区中有一个危险的观点，即您应该只验证由受信任的根证书签名的证书。 这种观点是完全错误的。

不知道还有这样的风景。 由根证书签名的证书并不能真正证明站点的安全性。 如果你想做坏事，获得匿名证书很便宜。

如果您遇到自签名证书，您应该好好验证它们。 这是完全可以的！ 将自签名证书添加到 .pem 文件并将其作为参数传递以进行验证！

用户需要一个安全通道来获取证书，就像一个内部可信网络。 但是如果服务器本身在同一个内网，就没有太大的收获。 但这无论如何都是用户决定的，我不能在我的模块中强加策略。

我在很大程度上同意

我提出了一些建议——我们默认禁用，但有自己的功能来重新启用它，或记录如何打开它。 我不希望用户不得不按照预期使用代码。 verify=False是一项功能，尽管不是最佳实践。 那不关我们的事。

我同意verify=False是一项功能，但我不同意它与params=或cert=处于同一级别。 这是一项默认为安全值且可能设置为不安全值的功能。 对于人们来说，为了权宜之计而将安全措施扔出窗外是一个巨大的、诱人的选择，我认为应该抵制这种冲动（但不是不允许）。 我将始终倾向于“你必须明确地不安全”的思想流派，我不在乎这是否意味着轻弹两个开关而不是一个。

无论如何，这是你的电话，不是我的。 =)

只是想说我同意@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 程序员在想要禁用警告时应该寻找的标准工具。 它是标准库的一部分，并且有很好的文档记录。

我建议在requests文档中加入对warnings的引用——或者如果你愿意，也可以使用方便的disable_warnings函数，只要有相应的enable_warnings功能（似乎没有这样的功能）。

再说一遍：我一般不想禁用警告。 当我_explicitly_在我的代码中设置 verify=False 时，我只希望这个特殊的警告消失。 可能还有其他有用的警告，与这个特殊的无用警告不同。 这有什么难理解的？！

@zaitcev冒着重复自己的风险：

requests.packages.urllib3.disable_warnings()

如果这对你来说太宽泛了：

from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

最后，请注意@zaitcev ：你会发现，采取你刚刚做的恼怒的语气根本不会为你赢得任何好处。 请记住，我们都是志愿者，我们可以用来为您打造产品的时间有限。 请尽量以您希望被对待的方式对待我们。

@zaitcev看起来这不会在请求模块本身中发生变化，但我希望您可以使用我在其他评论中添加的代码。 这应该允许您有选择地禁用 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 警告并为用户提出我自己的格式警告。 它确实要求发出两次请求。 编辑以减少except子句的广泛性。

except Exception:非常广泛。 你真的不想那样。

以上在某种程度上解决了本次讨论双方的担忧。

它不会抛出一些您可以捕获的 Exception 子类吗？

或使用logging.captureWarnings()

另一种方法是知道涉及 urllib3 并对其命名空间进行硬编码，请参阅 tuukkamustonen 的评论。 这是我的主要反对意见：他们本可以让它正常工作，我什至在拉取请求中提供了一个补丁。 但他们否认问题存在，并告诉所有用户想出糟糕的解决方法，例如“异常除外”或“来自 requests.packages.urllib3 的导入异常”。 在这一点上，有人不得不承认他们一直都错了，所以我们被困住了。

这是我的主要反对意见：他们本可以让它正常工作，我什至在拉取请求中提供了一个补丁。 但他们否认问题存在，并告诉所有用户想出糟糕的解决方法，例如“异常除外”或“来自 requests.packages.urllib3 的导入异常”。 在这一点上，有人不得不承认他们一直都错了，所以我们被困住了。

@zaitcev再次提醒您，这是一个尽其所能的志愿者社区。 我们已经让这个问题自由讨论，我们没有试图锁定它或阻止进一步讨论。 我们_听你的_。 我们没有立即同意你对情况的评估。 请考虑我们关心更多用例的可能性，而不仅仅是您的用例，我们需要平衡所有这些用例的需求。

至于您的拉取请求，由于您经常忽略的_非常具体的原因_，它被拒绝了！ 让我引用自己援引伊恩：

结束语是：“鉴于这主要在 urllib3 中并且依赖于那里的接受，我将关闭它，直到那里取得进展。 ”（强调我的。）

截至今天，我在 urllib3 中仍然没有看到与此问题相关的拉取请求或问题。 这个项目中的任何人都没有阻碍或阻止这项工作的发生，我们只是没有选择自己做，因为_我们目前不同意你的观点_。

然而，冒着再次陷入这个兔子洞的风险，让我重申：

这是我的主要反对意见：他们本可以让它正常工作。

我不相信你的补丁使这项工作“正确” 。 正如我在此线程中多次说过的那样，我认为当前的行为是可取的。 执行不安全的 TLS 请求是一个坏主意，应该告诫用户不要这样做。

我的立场是，用户_应该知道_他们何时发出未充分保护的 TLS 请求，尤其是在任何处理其密码的系统中。

在这个线程中有一个verify=False和verify=None之间以前不存在的一些区别，以便隐式地消除这些警告。 你会发现做前者比做后者容易得多。

+1 不区分 verify=False 和 verify=None。 我会支持：

• 添加新参数（例如 noInsecureWarnings），或
• 让请求拦截 urllib3 警告并发出自己的警告，所以 (a) 我可以抑制比 'requests.packages.urllib3.exceptions.InsecureRequestWarning' 不那么可怕的东西（无论如何它已经是特定于请求的，但如果请求迁移就会中断到不同的底层库），以及 (b) 警告可以指向特定于请求的 URL（当前 URL 不相关，因为警告已被阴影化！）

感谢所有支持请求的志愿者，无论这是否得到修复：这是一个很棒的图书馆:)

这是一个很棒的图书馆，感谢您的辛勤工作。

我在最近升级了我的 python 包并注意到大量新的 InsecurePlatformWarning 打印输出后遇到了这个问题。 所以我贡献了我的用例，我认为这很有说服力。

我正在使用请求来管理跨 4 个不同环境的 jenkins 服务器。 其中三个环境（开发、暂存、生产）都具有有效证书。 第 4 个环境是一个 vagrant virtual box，开发人员可以使用它在本地机器上测试更改。 这没有有效的证书，但作为策略问题，所有服务器配置都拒绝未加密的请求。

环境的 jenkins 连接设置（服务器名称、令牌等）包括用于关闭 ssl 验证的特定标志，仅在 vagrant 环境中设置为 True。

在我的设置中，全局禁用警告不是一个好主意，因为项目相当大并且可能会发出很多请求，无论是否使用请求库。 在范围内禁用警告没有问题，除了项目的一部分包括烧瓶应用程序和其他可能的多线程情况。

在我看来，似乎应该支持使用 verify=False 并按预期工作，没有警告。 由应用程序开发人员决定何时以及是否应该允许。 例如，如果我正在编写一个通用浏览器，那么如果不显示带有大量红色文本的大确认对话框，我将永远不会将其设置为 True。 但是，如果我拥有服务器和客户端，并且有自己不颁发证书的原因，我应该能够拥有干净的日志，而不是隐藏其他潜在问题。

由应用程序开发人员决定何时以及是否应该允许。

这个论点是我与你不同的地方。 我相信由开发人员决定何时应该使用它。 但我相信由 _user_ 决定该选择是否可以接受。 _关键_用户了解开发人员的选择何时将他们置于风险之中，并且他们能够评估该风险。

但是，如果我拥有服务器和客户端，并且有自己不颁发证书的原因，我应该能够拥有干净的日志，而不是隐藏其他潜在问题。

您可以通过使用日志上下文管理器来捕获警告来做到这一点。 我们还考虑让请求使此警告更具体地针对请求，以便更容易捕获，但这尚未发生。

我的情况类似于@jamie-sparked。

我理解 Lukasa 在加强安全方面的意义，但我认为您应该让您的用户决定什么对他们最有利。
Requests 是一个库，而不是最终用户应用程序。 IMO 您应该将开发人员视为您的用户。
如果应用程序开发人员决定关闭证书验证（即 verify=False），他们应对安全错误负责

作为开发人员，我重视灵活性，而不是试图决定我应该做什么的库。

顺便说一句，正如其他人所说，我发现请求 _excellent_ 并且我感谢您的所有努力。 谢谢。

@thalesac我们

将其视为纵深防御。 拿脚踏枪打个比方，我们递给你一把带保险的枪，里面没有子弹，还有一本杂志。 如果我们让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()
 -> 警告.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()
 -> 如果 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()
 -> 返回 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()
 -> 正文=正文，标题=标题）
 /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()
 -> 警告.warn((

以下是pip freeze的输出，我正在使用 debian 测试：

 argparse==1.2.1
 beautifulsoup4==4.4.1
水泥==2.6.2
 chardet==2.3.0
颜色==0.3.3
覆盖率==4.0.3
密码学==1.2.1
 distlib==0.2.1
 -e [email protected]:droope/droopescan.git@6524a9235e89a6fdb3ef304ee8dc4cb73eca0386#egg=droopescan-development
 enum34==1.1.2
 funcsigs==0.4
期货==3.0.4
 html5lib==0.999
 httplib2==0.9.1
 idna==2.0
 ip地址==1.0.16
 lxml==3.5.0
水银==3.5.2
模拟==1.3.0
 ndg-httpsclient==0.4.0
鼻子==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
报告错误==6.6.6
请求==2.9.1
回复==0.3.0
重试==1.3.3
六==1.10.0
 urllib3==1.13.1
轮==0.26.0
 wsgiref==0.1.2

谢谢，
佩德罗

disable_warnings不会阻止调用警告函数，它只是抑制输出。 如果其他一些代码启用所有警告，您可能会遇到问题。

嗨@卢卡萨，

我把断点放在 if 之后。 最后我停止使用 debian 测试，因为我遇到了太多问题，这很可能就是其中之一。 我会忽略我的评论，我不确定发生了什么，但这可能不会影响很多人。

谢谢！
佩德尔

是的，所以如果您使用的是来自 debian 的软件包，那么他们的 unvendoring 逻辑可能会在这里破坏一些东西。

想要通过指定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
...