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

Я думаю, вы можете отключить их на глобальном уровне с помощью модуля warnings . Кроме того, для работы с ведением журнала (если я правильно помню) вам нужно обратиться к urllib3 (и мы это документируем), поэтому я не против документировать это для пользователей, которые не собираются использовать проверку сертификата для HTTPS. соединения.

Я по-прежнему решительно выступаю за то, чтобы эти предупреждения оставались в силе. Да, они раздражают, но они есть не зря. Во всяком случае, у меня возникает соблазн выключить его и заменить на один из наших! = P

На данный момент довольно очевидно, что @Lukasa и я -1 по этой функции. @kennethreitz @shazow есть какие-нибудь мнения?

В некоторой степени я согласен с тем, что предупреждения важны, но я думаю, что есть несколько факторов, которые, возможно, необходимо учитывать.

С точки зрения разработчика, знаю, что я знаю об этом, я могу просто отключить это, если захочу. Я новичок в пакетах, поэтому, когда я читал документы в предупреждении, это решение на самом деле не сработало. Мне нравится идея @Lukasa о создании чего-то особенного для requests .

С точки зрения пользователя, я установил pyvmomi с pip сегодня, который использует requests во внутреннем устройстве. Это действительно непрозрачная ошибка, которая возвращается пользователю в случае, когда requests - это тихая вспомогательная библиотека.

Да, requests.packages.urllib3.disable_warnings() - это ярлык для его отключения с помощью фильтрации модуля предупреждений.

Я настоятельно рекомендую предупредить об этом. +0,5 при распространении urllib3, +1, если вы хотите приложить усилия и добавить специфичный для запросов. -1 за отсутствие предупреждения.

Если вы хотите, мы можем сделать настраиваемое предупреждающее сообщение urllib3, и вы можете переопределить его, чтобы в противном случае вы могли использовать ту же логику.

Еще раз, я не считаю это сообщение враждебным по отношению к пользователю, я считаю его чрезвычайно ценным. Теперь вы знаете, что pyvmomi отключил проверку сертификата TLS, что является довольно важной информацией!

Тем не менее, я не возражаю против того, чтобы у нас было больше запросов, чтобы заставить его замолчать.

Да, правда, я думаю, что это ошибка в pyvmomi . Если они не хотят так смущаться, им следует отключить предупреждения в своем инструменте. В нашу задачу не входит _не_ предупреждать пользователей о том, что соединения, устанавливаемые каким-либо инструментом, могут подвергнуть их атакам MITM, поскольку инструмент не выполняет проверку сертификата.

Спасибо за обсуждение, ребята! Я ценю всех, кто комментирует и помогает мне увидеть ценность того, как все делается, и почему. Мне было трудно разглядеть более общие случаи! :)

Буду работать над патчем сегодня, если позволит время, чтобы иметь способ замолчать "запросы". Обратная связь будет приветствоваться!

@invisiblethreat не стесняйтесь

Просто интересно, рассматривали ли вы случай, когда запросы используются в веб-перехватчике. Я должен подавить предупреждение, чтобы оно не загрязняло вывод JSON скрипта (или я что-то упускаю?)

@macterra Я не совсем понимаю. Вы ищете альтернативные стратегии для отключения предупреждения или ...?

Мне также крайне непонятно, почему ваш веб-перехватчик отключает проверку сертификата. Я бы хотел оставить это включенным.

Кроме того, если вы отправляете 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)

У меня есть 2 варианта для service_foo :

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 нарушена. Страница https://urllib3.readthedocs.org/en/latest/security.html, указанная в сообщении InsecureRequestWarning действительно предназначена для того, чтобы показать, как исправить проблемы на платформе. Если пользователь запрашивает пропустить проверку, не должно быть предупреждения, как если бы пользователь запрашивал URL-адрес http вместо https .

Когда пользователь явно запрашивает verify = False для определенного запроса, я не вижу смысла показывать предупреждение.

Кто такой «пользователь»? На протяжении всего вашего сообщения этот вопрос постоянно приходил мне в голову, потому что я считаю, что вы объединяете две аудитории.

Когда я как автор модуля устанавливаю verify = False, я устанавливаю его по запросу пользователя (или я злонамерен).

Или вы проявляете халатность. У вас были пользователи, которые жаловались, что они не могут взаимодействовать со своими самозаверяющими сертификатами, и поэтому вы отключили проверку сертификатов, несмотря на то, что отключение проверки сертификатов _не_ способ решения этой проблемы.

который убирает полезное предупреждение для тех запросов, которые некоторая другая часть приложения неосознанно делает небезопасно

Это предложение сбивает меня с толку. Он предполагает, что допустимо предупреждать, когда приложение _неизвестно_ делает небезопасные запросы, но что приложение, _сознательно_ отправляющее их, в каком-то смысле в порядке. Я не понимаю, как сознательное выполнение небезопасных запросов каким-либо образом должно считаться «более безопасным», чем выполнение этого неосознанно.

Кроме того, наличие предупреждения для тех запросов, проверка которых явно отключена пользователем.

Какой пользователь? Как отличить автора модуля от «пользователя», кем бы они ни были?

Предупреждение также не очень полезно для пользователя, поскольку в нем не упоминается URL-адрес конкретного запроса.

В предупреждении не следует указывать URL-адрес запроса, поскольку это может привести к возникновению спама с предупреждениями. Мы предупреждаем _once_, говоря, что «это приложение находится под угрозой», а не «это конкретное сообщение находится под угрозой».

Браузеры позволяют мне обходить проверки безопасности для отдельных URL-адресов, но продолжать проверять остальные, и мне это нравится.

Поставщики браузеров _предупреждают_, когда вы обращаетесь к URL-адресу с недопустимым сертификатом! Они печатают диалоговые окна и выделяют адресную строку красным цветом! Это именно то, что мы делаем. Мы не мешаем вам что-либо делать, мы просто говорим "эй, это плохо!" То, что вы просите нас сделать, - это то же самое, что просить поставщиков браузеров разрешить пользователям отключать это красное предупреждение для определенных URL-адресов, и я гарантирую, что они откажутся сделать это, потому что последствия для безопасности чудовищны.

Когда у меня есть инструмент, который общается с внутренним сервером с самозаверяющим сертификатом во внутренней сети, но также взаимодействует с внешними хостами, я действительно хочу проверить внешнюю связь.

Нет, вы хотите проверить _все_ сообщения. Проверьте самоподписанный сертификат! Убедитесь, что вы получили сертификат, который ожидали получить. verify=False следует рассматривать как кувалду подход к безопасности, фактически говоря: «Да ну, к черту безопасность, просто заставь ее работать». Это абсолютно нормально, вы имеете право так сказать, но мы обязаны назвать это небезопасным.

Я не думаю, что оба варианта хороши, но вариант 1 хуже, потому что он дает ложные срабатывания.

Вариант 1 не дает ложных срабатываний, он дает настоящие срабатывания. Связь с 10.0.0.1 _ небезопасна_, и мы не должны притворяться иначе.

Если бы я сделал это с помощью сценария оболочки, пользователь был бы счастливее и безопаснее.

Пользователь вполне может быть счастливее, но он не будет в большей безопасности. Они будут в такой же безопасности, как и раньше. Кажется, у вас сложилось впечатление, что отключение этого предупреждения каким-то волшебным образом заставляет пройти проверку сертификата, а это не так. Я коснусь этого еще раз в конце этого ответа.

Для меня имеет смысл только предупреждать, если конфигурация платформы Python нарушена.

Нет, мы должны потерпеть неудачу, если конфигурация платформы Python нарушена и вы не запрашивали непроверенные запросы. Если ваша платформа не может создавать безопасные TLS-соединения, то нам абсолютно не следует их делать, за исключением ситуации, когда наш пользователь прямо говорит нам не заботиться (установив verify=False ), и в этом случае мы должны предупредить, что то, что вы собираешься сделать опасно.

Я думаю, что вы заблуждаетесь, поэтому я хотел бы прояснить кое-что: невозможно сделать непроверенный запрос HTTPS с запросами без а) установки verify=False (наше поведение предупреждения) или б) умышленный саботаж модуля ssl . Мы не можем поймать б) и не предупредить об этом. Это единственная ситуация, которая может подпадать под возникшее вами понятие «проблемы с платформой». Рекомендации на странице справки urllib3 не относятся к нам, потому что мы предпринимаем все необходимые шаги, связанные с платформой, включая объединение доверенных сертификатов и ручную проверку сертификатов.

В веб-сообществе существует опасная точка зрения, что вам следует проверять только сертификаты, подписанные доверенными корневыми сертификатами. Эта точка зрения совершенно ошибочна. Если вы сталкиваетесь с самозаверяющими сертификатами, вам следует их проверить. Это вполне выполнимо! Добавьте самоподписанный сертификат в файл .pem и передайте его в качестве аргумента verify !

Если у вас возникли проблемы с объединением этого с прилагаемым файлом .pem , сообщите мне, и я улучшу mkcert.org, чтобы вы могли объединить свои собственные сертификаты с доверенными корнями. Но, пожалуйста, не делайте вид, что установка verify=False безопасна: это просто не так.

Кроме того, включение предупреждения для тех запросов, проверка которых явно отключена пользователем, также скрывает запросы, в которых пользователь хотел бы получить предупреждение, поскольку предупреждение выдается только один раз.

Это тоже немного сбивает с толку. Установив verify=False вы, возможно, явно отключите его только для этого запроса, но нет никакого способа передать это дальше той точки, где мы создаем наш запрос. Также нет причин передавать его дальше, потому что вы отключили проверку сертификата. Контекст, в котором вы это сделали, не имеет значения для нас или кого-либо, использующего ваше приложение.

То, что вы просите нас сделать, - это то же самое, что просить поставщиков браузеров разрешить пользователям отключать это красное предупреждение для определенных URL-адресов, и я гарантирую, что они откажутся сделать это, потому что последствия для безопасности чудовищны.

Мои браузеры позволяют мне постоянно принимать непроверенный сертификат, что «чудовищно небезопасно».

Связь с 10.0.0.1 небезопасна, и нам не следует делать вид, что это не так.

Соединение является небезопасным, так что вы не можете проверить цифровой сертификат, но проверка сертификата на самом деле не говорит вам, безопасен ли сервер, с которым вы разговариваете. Но когда я говорю с сервером в закрытой сети, я действительно могу убедиться в безопасности сервера.

Я думаю, что вы заблуждаетесь, поэтому я хотел бы кое-что прояснить: невозможно сделать непроверенный запрос HTTPS с запросами без a) установки verify = False (наше поведение предупреждения) или b) преднамеренно саботаж ssl

Я пытаюсь задаться вопросом, как я мог бы быть хорошим гражданином в своем модуле, уважая желание пользователя игнорировать проверки сертификатов и предупреждения для URL-адресов, которые они мне дают. И какое значение добавляет модель предупреждения. В каком случае запрос с verify=False должен отображать предупреждение для пользователя?

Я не понимаю, как механизм предупреждения может обнаружить небрежный код, поскольку он не может определить, сделан ли запрос из-за неаккуратного кодирования или из-за того, что пользователь запросил это. Я не думаю, что такой модуль, как requests должен диктовать политику безопасности. Я понял, что предупреждения обычно предназначены для разработчиков, чтобы они могли исправить неправильный код, но это предупреждение не похоже на это. Если предупреждение предназначено только для общего образования пользователя, у пользователя должен быть простой способ скрыть его.

Получение предупреждения - это не только косметическое средство, потому что оно портит вывод программы.

Я вижу только отрицательное значение предупреждения, поэтому я отключаю его в своем модуле, даже если мне не нравится скрывать там такое глобальное изменение политики.

В веб-сообществе существует опасная точка зрения, что вам следует проверять только сертификаты, подписанные доверенными корневыми сертификатами. Эта точка зрения совершенно ошибочна.

Не знал, что есть такая точка зрения. Сертификат, подписанный корневым сертификатом, на самом деле ничего не доказывает о безопасности сайта. Если вы хотите делать плохие вещи, получить анонимный сертификат дешево.

Если вы сталкиваетесь с самозаверяющими сертификатами, вам следует их проверить. Это вполне выполнимо! Добавьте самозаверяющий сертификат в файл .pem и передайте его в качестве аргумента для проверки!

Пользователю потребуется безопасный канал для получения сертификата, например внутренняя доверенная сеть. Но если сам сервер находится в той же внутренней сети, от этого мало что получится. Но в любом случае это решение пользователя, я не могу навязать политику в своем модуле.

Я по большей части согласен с @kankri . Это было изначальным замыслом дизайна.

Я предлагаю кое-что - отключить по умолчанию, но у нас есть собственная функция для повторного включения или документирования того, как ее включить. Я не хочу, чтобы пользователям приходилось уклоняться от использования кода по назначению. 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()

@Lukasa

Или просто сделайте это:

requests.packages.urllib3.disable_warnings()

За исключением того, что я не нахожу упоминания об этой функции в руководстве по запросам.

Хотя далеко не все об этом знают, я бы сказал, что модуль warnings _is_ стандартный инструмент, на который программист Python должен обратить внимание, когда он хочет отключить предупреждения. Он является частью стандартной библиотеки и хорошо документирован.

Я предлагаю поместить ссылку на warnings в документацию requests - или на удобную функцию 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 Exception: ОЧЕНЬ широкое. ты действительно этого не хочешь.

Вышеизложенное в некоторой степени снимает озабоченность обеих сторон этого обсуждения.

разве это не создает подкласс Exception, который вы можете поймать?

Или используйте logging.captureWarnings()

Альтернатива - знать, что urllib3 задействован, и жестко закодировать его пространство имен, см. Комментарий tuukkamustonen. Это было моим принципиальным возражением: они могли заставить все работать правильно, я даже предоставил патч в запросе на вытягивание. Но они отрицают, что проблема существует, и говорят всем пользователям придумать ужасные обходные пути, такие как «кроме исключений» или «из исключений импорта request.packages.urllib3». На этом этапе кто-то должен признать, что был неправ, и поэтому мы застряли.

Это было моим принципиальным возражением: они могли заставить все работать правильно, я даже предоставил патч в запросе на вытягивание. Но они отрицают, что проблема существует, и говорят всем пользователям придумать ужасные обходные пути, такие как «кроме исключений» или «из исключений импорта request.packages.urllib3». На этом этапе кто-то должен признать, что был неправ, и поэтому мы застряли.

@zaitcev Еще раз, позвольте мне напомнить вам, что это сообщество добровольцев, которое делает все возможное. Мы оставили этот вопрос свободным для обсуждения, мы не пытались заблокировать его или предотвратить дальнейшее обсуждение. Мы _слушаем вас_. Мы не сразу соглашаемся с вашей оценкой ситуации. Пожалуйста, рассмотрите возможность того, что нас интересует больше вариантов использования, чем просто ваш, и что нам нужно сбалансировать потребности всех из них.

Что касается вашего запроса на перенос, он был отклонен по очень конкретной причине, которую вы постоянно игнорируете! Позвольте процитировать самого себя, цитируя Яна :

Заключительное заявление было: «Учитывая, что это в основном в urllib3 и будет зависеть от принятия там, я закрываю это до тех пор, пока там не будет достигнут прогресс ». (Выделено

На сегодняшний день я все еще не вижу связанных запросов на перенос или проблем с этой проблемой в urllib3. Никто из участников этого проекта не стоял на вашем пути и не препятствовал проведению этой работы, мы просто не решили делать это сами, потому что _мы в настоящее время не согласны с вами_.

Однако, рискуя снова попасть в эту кроличью нору, позвольте мне повторить:

Это было моим главным возражением: они могли бы заставить это работать правильно.

Я не верю, что ваш патч делает эту работу «правильной» . Как я много раз говорил в этой теме, я считаю текущее поведение желательным. Выполнение небезопасных запросов TLS - плохая идея, и пользователей следует предостеречь от этого.

Моя позиция состоит в том, что пользователь _ заслуживает знать_, когда он делает запрос TLS, который не защищен должным образом, особенно в любой системе, которая обрабатывает их пароли.

В этом потоке есть verify=False и verify=None должно быть добавлено, чтобы неявно заглушить эти предупреждения. Вам будет намного проще сделать первое, чем второе.

+1, чтобы не различать verify = False и verify = None. Я бы поддержал либо:

• добавление нового параметра (скажем, noInsecureWarnings) или
• запросы перехватывают предупреждение urllib3 и выдают одно из них, поэтому (а) я могу подавить что-то менее пугающее, чем 'requests.packages.urllib3.exceptions.InsecureRequestWarning' (которое в любом случае уже зависит от запросов, но сломается, если запросы мигрируют в другую базовую библиотеку), и (б) предупреждение может указывать на URL-адрес конкретного запроса (текущий URL-адрес не имеет значения, поскольку предупреждение было затенено!)

И спасибо всем добровольцам за поддержку запросов, независимо от того, будет ли это исправлено: это отличная библиотека :)

Это отличная библиотека, спасибо за вашу тяжелую работу.

Я столкнулся с этой проблемой после недавнего обновления моих пакетов python и заметил множество новых распечаток InsecurePlatformWarning. Итак, я предлагаю свой вариант использования, который, на мой взгляд, убедителен.

Я использую запросы для управления серверами jenkins в 4 разных средах. У всех трех сред (dev, staging, production) есть действующие сертификаты. Четвертая среда - это бродячий виртуальный ящик, который разработчики могут использовать для тестирования изменений на своих локальных машинах. У него нет действующего сертификата, но в соответствии с политикой все конфигурации сервера отклоняют незашифрованные запросы.

Параметры подключения jenkins (имя сервера, токен и т. Д.) Для среды включают специальный флаг для отключения проверки ssl, который имеет значение True только для бродячей среды.

В моей настройке глобальное отключение предупреждения было бы плохой идеей, потому что проект довольно большой и может выполняться множество запросов с библиотекой запросов или без нее. Отключить предупреждение в области действия можно, за исключением того, что часть проекта включает приложение фляги и другие, возможно, многопоточные случаи.

На мой взгляд, похоже, что использование verify = False должно поддерживаться и работать, как ожидалось, без предупреждений. Разработчик приложения должен решить, когда и следует ли это допускать. Например, если бы я писал браузер для общего использования, я бы никогда не установил для него значение True без отображения большого диалогового окна подтверждения с большим количеством красного текста. Но если я владею сервером и клиентом и у меня есть собственные причины не выдавать сертификат, я должен иметь возможность иметь чистый журнал и не скрывать другие потенциальные проблемы.

Разработчик приложения должен решить, когда и следует ли это допускать.

В этом утверждении я не согласен с вами. Я считаю, что разработчик должен решить, когда им следует его использовать. Но я считаю, что _user_ должен решить, приемлем ли этот выбор. _Critical_, чтобы пользователи понимали, когда они подвергаются риску из-за выбора разработчика, и чтобы они могли оценить этот риск.

Но если я владею сервером и клиентом и у меня есть собственные причины не выдавать сертификат, я должен иметь возможность иметь чистый журнал и не скрывать другие потенциальные проблемы.

И вы можете сделать это, используя диспетчер контекста ведения журнала для записи предупреждения. Мы также рассматриваем возможность сделать это предупреждение более специфичным для запросов, чтобы его было легче захватить, но этого пока не произошло.

У меня ситуация похожая на @ jamie-sparked.

Я понимаю точку зрения Лукасы по обеспечению безопасности, но я думаю, что вы должны позволить ВАШЕМУ пользователю решать, что для него лучше.
Запросы - это библиотека, а не приложение для конечного пользователя. ИМО, вы должны рассматривать разработчиков как своих пользователей.
Разработчики приложений должны нести ответственность за ошибки безопасности, если они решат отключить проверку сертификата (т.е. verify = False).

Как разработчик, я ценю гибкость, а не библиотеку, которая пытается диктовать мне, что мне делать.

Кстати, как говорили другие, я нахожу запросы _ отличные_, и я ценю все ваши усилия. Спасибо.

@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 ()
 -> warnings.warn ((
 (Pdb) bt
 / корень / 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) по умолчанию ()
 -> 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 = заголовки)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (480) получить ()
 -> return self.request ('ПОЛУЧИТЬ', URL, ** kwargs)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (468) запрос ()
 -> resp = self.send (подготовка, ** send_kwargs)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (576) send ()
 -> r = adapter.send (запрос, ** 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 ()
 -> 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 [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
 ipaddress == 1.0.16
 lxml == 3.5.0
 mercurial == 3.5.2
 макет == 1.3.0
 ndg-httpsclient == 0.4.0
 нос == 1.3.7
 pbr == 1.8.1
 pyOpenSSL == 0.15.1
 пясн1 == 0.1.9
 pycurl == 7.21.5
 pystache == 0.5.4
 python-apt == 1.1.0b1
 питон-дебиан == 0.1.27
 python-debianbts == 2.6.0
 reportbug == 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 не предотвращает вызов функции предупреждения, а просто подавляет вывод. Вы можете столкнуться с проблемами, если какой-либо другой фрагмент кода включает все предупреждения.

Привет @Lukasa!

Я ставлю точку останова после if. В конце концов, я перестал использовать тестирование Debian, так как столкнулся со слишком большим количеством проблем, и это вполне может быть одной из них. Я бы просто проигнорировал свой комментарий, я не уверен, что произошло, но, вероятно, это не то, что затронет многих людей.

Спасибо!
Педр

Да, так что, если вы использовали пакет от 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
...