Requests: verify=False et request.packages.urllib3.disable_warnings()

Je pense que vous pouvez les désactiver au niveau global avec le module warnings . De plus, pour travailler avec la journalisation (si je me souviens bien), vous devez accéder à urllib3 (et nous le documentons), donc je ne suis pas contre le documenter pour les utilisateurs qui n'utiliseront pas la vérification de certificat pour HTTPS Connexions.

Je reste fermement en faveur du maintien de ces avertissements. Oui, ils sont ennuyeux, mais ils sont aussi là pour une raison. Si quoi que ce soit, je suis tenté de l'éteindre et de le remplacer par l'un des nôtres ! =P

À ce stade, il est assez évident que @Lukasa et moi sommes -1 sur cette fonctionnalité. @kennethreitz @shazow des avis ?

Dans une certaine mesure, je conviens que les avertissements sont importants, mais je pense qu'il y a plusieurs facteurs qui pourraient devoir être pris en considération.

Du point de vue du développeur, sachez que je sais à ce sujet, je peux simplement désactiver cela si j'en ai envie. Je suis plus nouveau dans les packages, donc quand j'ai lu la documentation, dans l'avertissement, cette solution n'a pas vraiment fonctionné. J'aime l'idée présentée par @Lukasa de créer quelque chose de spécifique à requests .

Du point de vue de l'utilisateur, j'ai installé pyvmomi avec pip aujourd'hui, qui utilise requests dans ses composants internes. C'est vraiment une erreur non transparente qui est renvoyée à l'utilisateur dans un cas où requests est une bibliothèque de support silencieuse.

Oui, requests.packages.urllib3.disable_warnings() est un raccourci pour le désactiver en utilisant le filtrage du module d'avertissements.

Je recommande fortement d'avoir une sorte d'avertissement à cet effet. +0,5 pour la propagation de l'urllib3 one, +1 si vous voulez faire l'effort et en ajouter un spécifique aux requêtes. -1 sur n'avoir aucun avertissement.

Si vous le souhaitez, nous pouvons rendre le message d'avertissement urllib3 configurable et vous pouvez le remplacer afin que vous puissiez utiliser la même logique autrement.

Encore une fois, je ne considère pas ce message comme hostile aux utilisateurs, je le considère comme extrêmement précieux. Vous savez maintenant que pyvmomi a désactivé la vérification du certificat TLS, ce qui est une information assez importante !

Cela dit, je ne m'oppose pas à ce que nous ayons un moyen plus exigeant de le faire taire.

Ouais, vraiment je pense que c'est un bug dans pyvmomi . S'ils ne veulent pas être gênés comme ça, ils devraient désactiver les avertissements dans leur outil. Ce n'est pas notre travail de _pas_ avertir les utilisateurs que les connexions qu'un outil établit pourraient les exposer à des attaques MITM car l'outil n'effectue pas de vérification de certificat.

Merci pour la discussion les gens ! J'apprécie tout le monde qui commente et m'aide à voir la valeur de la façon dont les choses sont faites et pourquoi. J'avais du mal à voir les cas plus généraux ! :)

Fonctionnera sur un patch aujourd'hui, si le temps le permet, pour avoir un moyen "demandes" de faire taire. Les retours seront les bienvenus !

@invisiblethreat n'hésitez pas à

Je me demandais juste si vous aviez envisagé le cas où les requêtes sont utilisées dans un webhook. Je dois supprimer l'avertissement afin qu'il ne pollue pas la sortie JSON du script (ou est-ce que j'ai raté quelque chose ?)

@macterra Je ne suis pas sûr de comprendre. Recherchez-vous des stratégies alternatives pour désactiver l'avertissement ou ... ?

Je ne comprends pas non plus très bien pourquoi votre webhook désactive la vérification des certificats. Je voudrais laisser ça.

De plus, si vous envoyez stdout à partir d'un script pour obtenir les résultats, des avertissements sortiront de stderr afin qu'ils ne doivent pas polluer votre sortie JSON.

D'accord, si l'avertissement est sur stderr, pas de problème. Je ne pouvais pas dire en regardant la sortie dans la console, mon erreur.

Je pense que nous devrions personnaliser cela pour pointer vers la documentation des requêtes au lieu de la documentation de urllib3.

Je ne suis pas sûr de comprendre à quoi sert cette fonction d'avertissement et comment l'avertissement est censé être contrôlé.

J'ai un module qui utilise requests et doit faire des requêtes avec l'argument verify=False . Cela fait que les utilisateurs de mon module voient l'avertissement inutile. Les avertissements inutiles rendent les avertissements importants plus difficiles à voir,

Il serait logique que mon module désactive l'avertissement, mais alors _je désactiverais l'avertissement également dans tout autre module_ en utilisant requests dans l'application !

Les choses ne vont pas mieux si je dois demander à l'utilisateur de mon module de désactiver l'avertissement : le fait que j'utilise requests n'est normalement qu'un détail d'implémentation invisible que l'utilisateur ne devrait pas avoir besoin de savoir. Et l'utilisateur n'aurait toujours que la possibilité de tout faire taire ou de noter.

Je ne pense pas que les avertissements mondiaux seront utiles.

Je pourrais sous-classer urllib3.HTTPSConnectionPool et remplacer _validate_conn() et faire en sorte que requests utilise dans mon module pour éviter de cacher les avertissements d'autres modules, mais cela semble être trop de travail pour une chose simple .

Je ne suis pas sûr de comprendre à quoi sert cette fonction d'avertissement

fait que les utilisateurs de mon module voient l'avertissement inutile.

Lorsque vous définissez verify=False vous ne sécurisez plus vos connexions réseau. Cela, à mon humble avis, n'est _pas_ un avertissement inutile, c'est un avertissement extrêmement pertinent. Vos utilisateurs, qui n'avaient auparavant aucune idée que vous ne vérifiiez pas les certificats, savent maintenant que cela est vrai.

Si l'avertissement n'est pas valable pour votre module, il est probable qu'il ne l'est pas pour un autre module de l'application (une fois que vous avez supprimé la sécurité d'un point du réseau, il ne sert à rien de le répéter partout ailleurs). Je ne vois pas vraiment de problème à le désactiver globalement.

Lorsque l'utilisateur demande explicitement verify=False pour une demande particulière, je ne vois pas l'intérêt d'afficher un avertissement. Lorsque, en tant qu'auteur de module, je définis verify=False , je le définis à la demande de l'utilisateur (ou je suis malveillant, mais l'avertissement n'aide pas non plus, car je peux désactiver les avertissements). En effet, je veux éviter d'être malveillant et ne pas faire taire globalement les avertissements, car cela supprime l'avertissement utile pour les demandes qu'une autre partie de l'application fait sans le savoir de manière non sécurisée.

En outre, l'activation de l'avertissement pour les demandes pour lesquelles la vérification est explicitement désactivée par l'utilisateur masque également les demandes pour lesquelles l'utilisateur souhaite recevoir l'avertissement, car l'avertissement n'est donné qu'une seule fois. L'avertissement n'est pas non plus vraiment utile pour l'utilisateur, car il ne mentionne pas l'URL de la demande particulière.

Je ne suis pas d'accord pour dire que la suppression de la sécurité dans un point du réseau rend les contrôles de sécurité inutiles dans l'application, pas plus que les fournisseurs de navigateurs. Les navigateurs me permettent de contourner les contrôles de sécurité pour les URL individuelles, mais continuent de vérifier le reste et j'aime ça.

Lorsque j'ai un outil qui communique avec un serveur interne avec un certificat auto-signé dans un réseau interne, mais communique également avec des hôtes externes, je souhaite vérifier la communication externe. Ce serait la situation dans laquelle j'aimerais, en tant qu'utilisateur, voir des avertissements concernant les demandes accidentellement non sécurisées.

Considérez que je gagne service_foo et que quelqu'un l'utilise dans une application :

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)

J'ai 2 options pour service_foo :

1. Je garde l'avertissement de sécurité global activé
   
   
   
   • L'utilisateur reçoit toujours un avertissement lorsque l'application parle à https://10.0.0.1
   
   
   • L'utilisateur ne reçoit jamais d'avertissement même si la requête à https://example.com/submit n'est pas sûre
   
   
2. Désactiver l'avertissement de sécurité global :
   
   
   
   • L'utilisateur ne reçoit jamais d'avertissement même si la requête à https://example.com/submit n'est pas sûre
   
   

Je ne pense pas que l'une ou l'autre option soit bonne, mais l'option 1 est pire, car elle donne de fausses alarmes. Mais je ne suis pas à l'aise pour que les contrôles de sécurité soient désactivés pour l'utilisateur comme effet secondaire de l'utilisation de mon module.

Si je faisais cela avec un script shell, l'utilisateur serait plus heureux et plus en sécurité :

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

Pour moi, cela n'a de sens que de donner un avertissement si la configuration de la plate-forme Python est cassée. La page https://urllib3.readthedocs.org/en/latest/security.html liée dans le message InsecureRequestWarning est en effet conçue pour montrer comment résoudre les problèmes de la plate-forme. Si l'utilisateur demande d'ignorer la vérification, il ne devrait pas y avoir d'avertissement comme il n'y a pas d'avertissement si l'utilisateur demande une URL http au lieu d'une https .

Lorsque l'utilisateur demande explicitement verify=False pour une demande particulière, je ne vois pas l'intérêt d'afficher un avertissement.

Qui est « l'utilisateur » ? Tout au long de votre message, cette question m'est revenue à l'esprit, car je pense que vous confondez deux publics.

Lorsque, en tant qu'auteur de module, je définis verify=False, je le définis à la demande de l'utilisateur (ou je suis malveillant).

Ou vous êtes négligent. Des utilisateurs se sont plaints qu'ils ne pouvaient pas interagir avec leurs certificats auto-signés et vous avez donc désactivé la vérification des certificats, malgré le fait que désactiver la vérification des certificats n'est _pas_ le moyen de résoudre ce problème.

qui supprime l'avertissement utile pour ces demandes qu'une autre partie de l'application fait sans le savoir de manière non sécurisée

Cette phrase me déroute. Cela suggère qu'il est acceptable d'avertir lorsqu'une application effectue _inconsciemment_ des requêtes non sécurisées, mais qu'une application qui les effectue _consciemment_ est en quelque sorte OK. Je ne vois pas en quoi faire sciemment des demandes non sécurisées devrait être considéré de quelque manière que ce soit comme «plus sécurisé» que de le faire sans le savoir.

En outre, l'avertissement est activé pour les demandes pour lesquelles la vérification est explicitement désactivée par l'utilisateur

Quel utilisateur ? Comment faire la distinction entre l'auteur du module et « l'utilisateur », quel qu'il soit ?

L'avertissement n'est pas non plus vraiment utile pour l'utilisateur, car il ne mentionne pas l'URL de la demande particulière.

L'avertissement ne doit pas mentionner l'URL de la requête, car cela risquerait de générer du spam d'avertissement. Nous avertissons _une fois_ en disant "cette application est en danger", et non "cette communication particulière est en danger".

Les navigateurs me permettent de contourner les contrôles de sécurité pour les URL individuelles, mais continuent de vérifier le reste et j'aime ça.

Les fournisseurs de navigateurs _avertissent_ lorsque vous accédez à une URL avec un certificat invalide ! Ils impriment des boîtes de dialogue et mettent en évidence la barre d'URL en rouge ! C'est exactement ce que nous faisons. Nous ne vous empêchons pas de faire quoi que ce soit, nous disons simplement "hey, c'est mauvais!" Ce que vous nous demandez de faire est la même chose que de demander aux fournisseurs de navigateurs d'autoriser les utilisateurs à désactiver cet avertissement rouge pour des URL particulières, et je vous garantis qu'ils refuseront de le faire car les implications en matière de sécurité sont monstrueuses.

Lorsque j'ai un outil qui communique avec un serveur interne avec un certificat auto-signé dans un réseau interne, mais communique également avec des hôtes externes, je souhaite vérifier la communication externe.

Non, vous voulez vérifier _tout_ la communication. Vérifiez le certificat auto-signé ! Validez que vous avez obtenu le certificat que vous vous attendiez à obtenir. verify=False devrait être considéré comme une approche de la sécurité à coup de marteau, en disant en fait "Vissez la sécurité, faites-le fonctionner". C'est très bien, vous avez le droit de le dire, mais nous avons l'obligation de le qualifier d'insécurité.

Je ne pense pas que l'une ou l'autre option soit bonne, mais l'option 1 est pire, car elle donne de fausses alarmes.

L'option 1 ne donne pas de fausses alarmes, elle donne de vraies alarmes. La communication vers 10.0.0.1 est _non sécurisée_, et nous ne devrions pas prétendre le contraire.

Si je faisais cela avec un script shell, l'utilisateur serait plus heureux et plus en sécurité.

L'utilisateur peut bien être plus heureux, mais il ne serait pas plus en sécurité. Ils seraient exactement aussi en sécurité qu'avant. Vous semblez avoir l'impression que la désactivation de cet avertissement fait en quelque sorte comme par magie disparaître la vérification du certificat, et ce n'est pas le cas. J'y reviendrai à la fin de cette réponse.

Pour moi, cela n'a de sens que de donner un avertissement si la configuration de la plate-forme Python est cassée.

Non, nous devrions échouer durement si la configuration de la plate-forme Python est cassée et que vous n'avez pas demandé de requêtes non vérifiées. Si votre plate-forme ne peut pas établir de connexions TLS sécurisées, nous ne devrions absolument pas les établir, sauf dans le cas où notre utilisateur nous dit expressément de ne pas nous en soucier (en définissant verify=False ), auquel cas nous devons avertir que ce que vous êtes sur le point de faire est dangereux.

Je pense que vous travaillez sur un malentendu, alors j'aimerais être très clair : il n'y a aucun moyen de faire une requête HTTPS non validée avec des requêtes sans a) définir verify=False (notre comportement d'avertissement) ou b) saboter délibérément le module ssl . Nous ne pouvons pas attraper b) et ne pas avertir. C'est la seule situation qui relèverait de la notion que vous avez évoquée de "problèmes avec la plate-forme". Les conseils sur la page d'aide d'urllib3 ne s'appliquent pas à nous car nous prenons toutes les étapes nécessaires liées à la plate-forme, y compris le regroupement des certificats de confiance et la vérification manuelle des certificats.

Il existe un point de vue dangereux dans la communauté Web selon lequel vous ne devez vérifier que les certificats signés par des certificats racine de confiance. Cette vision est totalement erronée. Si vous rencontrez des certificats auto-signés, vous devriez les valider. C'est tout à fait faisable ! Ajoutez le certificat auto-signé à un fichier .pem et transmettez-le en argument à verify !

Si vous rencontrez des problèmes pour combiner cela avec le fichier .pem fourni, faites-le moi savoir et j'améliorerai mkcert.org pour vous permettre de concaténer vos propres certificats avec les racines de confiance. Mais s'il vous plaît, ne prétendez pas que le réglage verify=False est sûr : ce n'est tout simplement pas le cas.

En outre, l'activation de l'avertissement pour les demandes pour lesquelles la vérification est explicitement désactivée par l'utilisateur masque également les demandes pour lesquelles l'utilisateur souhaite recevoir l'avertissement, car l'avertissement n'est donné qu'une seule fois.

C'est aussi un peu déroutant. En définissant verify=False vous le désactivez peut-être explicitement pour cette seule demande, mais il n'y a aucun moyen de le transmettre au-delà du point où nous construisons notre demande. Il n'y a également aucune raison de le transmettre au-delà de ce point, car vous avez désactivé la vérification du certificat. Le contexte dans lequel vous l'avez fait est sans conséquence pour nous ou pour toute personne utilisant votre application.

Ce que vous nous demandez de faire est la même chose que de demander aux fournisseurs de navigateurs d'autoriser les utilisateurs à désactiver cet avertissement rouge pour des URL particulières, et je vous garantis qu'ils refuseront de le faire car les implications en matière de sécurité sont monstrueuses.

Mes navigateurs me permettent d'accepter en permanence un certificat non vérifié, qui est "monstrueusement non sécurisé".

La communication vers 10.0.0.1 n'est pas sécurisée, et nous ne devrions pas prétendre le contraire.

La connexion n'est pas sécurisée dans la mesure où vous ne pouvez pas vérifier un certificat numérique, mais la vérification d'un certificat ne vous dit pas vraiment si le serveur avec lequel vous parlez est sécurisé. Mais quand je parle à un serveur dans un réseau fermé, je peux vraiment m'assurer de la sécurité du serveur.

Je pense que vous travaillez sur un malentendu, alors j'aimerais être très clair : il n'y a aucun moyen de faire une requête HTTPS non validée avec des requêtes sans a) définir verify=False (notre comportement d'avertissement) ou b) délibérément saboter le ssl

J'essaie de me demander comment je pourrais être un bon citoyen dans mon module en honorant le souhait de l'utilisateur d'ignorer les vérifications de certificat et les avertissements pour l'URL qu'ils me donnent. Et quelle valeur ajoute le modèle d'avertissement. Quel est le cas où une requête avec verify=False devrait afficher un avertissement à l'utilisateur ?

Je ne vois pas comment le mécanisme d'avertissement peut intercepter du code négligent, car il ne peut pas distinguer si une demande est faite à cause d'un codage bâclé ou parce qu'un utilisateur l'a demandé. Je ne pense pas qu'un module comme requests devrait dicter une politique de sécurité non plus. J'ai compris que les avertissements sont généralement destinés aux développeurs afin qu'ils puissent corriger le code incorrect, mais cet avertissement n'est pas comme ça. Si l'avertissement est uniquement destiné à la formation générale de l'utilisateur, il devrait y avoir un moyen facile pour l'utilisateur de le masquer.

Obtenir l'avertissement n'est pas seulement cosmétique non plus, car cela perturbe la sortie d'un programme.

Je ne vois que la valeur négative de l'avertissement, donc je le désactive dans mon module même si je déteste cacher un tel changement de politique globale là-bas.

Il existe un point de vue dangereux dans la communauté Web selon lequel vous ne devez vérifier que les certificats signés par des certificats racine de confiance. Cette vision est totalement erronée.

Je ne savais pas qu'il y avait une vue comme ça. Un certificat signé par un certificat racine ne prouve vraiment rien sur la sécurité du site. Il est bon marché d'obtenir un certificat anonyme si vous voulez faire de mauvaises choses.

Si vous rencontrez des certificats auto-signés, vous devriez les valider. C'est tout à fait faisable ! Ajoutez le certificat auto-signé à un fichier .pem et transmettez-le en argument à vérifier !

L'utilisateur aurait besoin d'un canal sécurisé pour obtenir le certificat, comme un réseau de confiance interne. Mais si le serveur est lui-même dans le même réseau interne, il n'y a pas grand chose à gagner. Mais c'est en tout cas quelque chose que l'utilisateur décide, je ne peux pas imposer de politique dans mon module.

Je suis d'accord avec @kankri , pour la plupart. C'était l'intention de conception originale.

Je propose quelque chose - que nous désactivons par défaut mais que nous ayons notre propre fonction pour le réactiver ou documenter comment l'activer. Je ne veux pas que les utilisateurs aient à faire tout leur possible pour utiliser le code comme prévu. verify=False est une fonctionnalité, bien qu'il ne s'agisse pas d'une des meilleures pratiques. Ce n'est pas notre affaire.

Je suis d'accord que verify=False est une fonctionnalité, mais je ne suis pas d'accord que ce soit une fonctionnalité au même niveau que params= ou cert= . C'est une fonctionnalité qui prend par défaut une valeur sécurisée et peut être définie sur une valeur non sécurisée. C'est une option géante et tentante pour les gens de jeter la sécurité par la fenêtre par souci d'opportunité, et je pense que cette impulsion doit être combattue (mais pas rejetée). Je pencherai toujours pour l'école de pensée « vous devez explicitement être peu sûr de vous », et je me fiche que cela signifie appuyer sur deux interrupteurs et pas un.

Quoi qu'il en soit, c'est votre appel pas le mien. =)

Je voulais juste dire que je suis d'accord avec @kankri et cette remarque de @kennethreitz

verify=False est une fonctionnalité, bien qu'il ne s'agisse pas d'une des meilleures pratiques. Ce n'est pas notre affaire.

le résume bien.

Pour ceux qui souhaitent également désactiver les avertissements, voici comment procéder. Vous devez utiliser les modules d'avertissements , qui font partie de la bibliothèque standard :

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)

Cela configure un filtre d'avertissement qui ignorera tout avertissement de la catégorie InsecureRequestWarning . La sortie ressemble à :

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

(Le site de test renvoie une page 403 Interdit, mais ce n'est pas important ici.)

Notez que vous devez utiliser la classe du package urllib3 fourni, et non la classe d'un package urllib3 niveau supérieur, si vous en avez un installé.

Vous pouvez (et devriez probablement) créer une petite fonction qui utilise le gestionnaire de contexte dans la plus petite région de code possible :

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

Ou faites simplement ceci :

requests.packages.urllib3.disable_warnings()

@Lukasa

Ou faites simplement ceci :

requests.packages.urllib3.disable_warnings()

Sauf que je ne trouve aucune mention de cette fonction dans le manuel des requêtes.

Bien qu'il soit loin de tout le monde qui le connaisse, je dirais que le module warnings _est_ l'outil standard qu'un programmeur Python devrait utiliser lorsqu'il souhaite désactiver les avertissements. Il fait partie de la bibliothèque standard et est bien documenté.

Je suggère de mettre une référence à warnings dans la documentation requests — ou à la fonction de commodité disable_warnings si vous le souhaitez, tant qu'il y a un enable_warnings fonction (il semble qu'il n'y ait pas une telle fonction ).

Encore une fois : je ne veux pas désactiver les avertissements en général. Je veux juste que cet avertissement particulier disparaisse lorsque je définis _explicitement_ verify=False dans mon code. Il peut y avoir d'autres avertissements utiles, contrairement à cet avertissement particulier, inutile. Qu'est-ce qui est si difficile à comprendre à ce sujet ?!

@zaitcev Au risque de me répéter :

requests.packages.urllib3.disable_warnings()

Et si même cela est trop large pour vous :

from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

Enfin, une note, @zaitcev : vous constaterez que prendre le ton exaspéré que vous venez de prendre ne vous gagne aucune faveur. N'oubliez pas que nous sommes tous des bénévoles, et que nous avons un temps limité à consacrer pour vous construire des choses. Veuillez essayer de nous traiter de la manière dont vous aimeriez être traité.

@zaitcev Il ne semble pas que cela changera dans le module de requêtes lui-même, mais j'espère que vous pourrez utiliser le code que j'ai mis dans mon autre commentaire . Cela devrait vous permettre de désactiver sélectivement les avertissements émis par urllib3.

Vous pouvez également le supprimer avec :

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

Dans mon cas, je n'utilise pas directement les requêtes, donc une suppression comme celle-ci me permet de m'inquiéter un peu moins d'être cassé plus tard.

@zaitcev En

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 Cela laisserait les avertissements désactivés pour toutes les demandes ultérieures.

En rassemblant d'autres exemples, j'ai étendu le Session par défaut (comme requests.get et d'autres raccourcis créent un Session temporaire, de toute façon):

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)

Désactiver tous les avertissements de requests est probablement une mauvaise idée, un peu mieux pourrait être :

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

Pour résumer comment j'ai géré ça :

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")

Cela me permet de vérifier si une requête n'est pas sécurisée, de masquer l'avertissement urllib et de déclencher un avertissement de mon propre formatage pour l'utilisateur. Cela nécessite que la demande soit faite deux fois. Modifié pour rendre la clause except moins large.

except Exception: est TRÈS large. tu ne veux vraiment pas ça.

Ce qui précède répond en partie aux préoccupations des deux côtés de cette discussion.

ne lance-t-il pas une sous-classe d'exception que vous pouvez attraper à la place ?

Ou utilisez logging.captureWarnings()

L'alternative est de savoir que urllib3 est impliqué et de coder en dur son espace de noms, voir le commentaire de tuukkamustonen. C'était ma principale objection : ils auraient pu le faire fonctionner correctement, j'ai même fourni un patch dans une pull request. Mais ils nient que le problème existe et disent à tous les utilisateurs de trouver des solutions de contournement terribles comme "except Exception" ou "from request.packages.urllib3 import exceptions". À ce stade, quelqu'un doit admettre qu'il s'est trompé depuis le début et nous sommes donc coincés.

C'était ma principale objection : ils auraient pu le faire fonctionner correctement, j'ai même fourni un patch dans une pull request. Mais ils nient que le problème existe et disent à tous les utilisateurs de trouver des solutions de contournement terribles comme "except Exception" ou "from request.packages.urllib3 import exceptions". À ce stade, quelqu'un doit admettre qu'il s'est trompé depuis le début et nous sommes donc coincés.

@zaitcev Encore une fois, permettez-moi de vous rappeler qu'il s'agit d'une communauté de bénévoles qui fait de son mieux. Nous avons laissé ce problème libre pour discussion, nous n'avons pas essayé de le verrouiller ou d'empêcher d'autres discussions. Nous _vous écoutons_. Ce que nous ne faisons pas, c'est immédiatement d'accord avec votre évaluation de la situation. Veuillez considérer la possibilité que nous nous soucions de plus de cas d'utilisation que simplement le vôtre, et que nous devions équilibrer les besoins de chacun d'eux.

Quant à votre pull request, elle a été rejetée pour une _raison très précise_ que vous ignorez constamment ! Permettez-moi de me citer en citant Ian :

La déclaration de clôture était : "Étant donné qu'il s'agit principalement de urllib3 et que cela dépendrait de l'acceptation, je ferme ceci jusqu'à ce que des progrès aient été accomplis. " (C'est moi qui souligne.)

À ce jour, je ne vois toujours aucune demande d'extraction ou problème associé à ce problème dans urllib3. Personne de ce projet n'a fait obstacle à votre chemin ou empêché ce travail de se produire, nous n'avons tout simplement pas choisi de le faire nous-mêmes car _nous ne sommes actuellement pas d'accord avec vous_.

Cependant, au risque de retomber dans ce terrier de lapin, permettez-moi de réitérer :

C'était ma principale objection : ils auraient pu le faire fonctionner correctement.

Je ne crois pas que votre patch rende ce travail "correct" . Comme je l'ai dit à plusieurs reprises dans ce fil, je considère que le comportement actuel est souhaitable. Faire des requêtes TLS non sécurisées est une mauvaise idée, et les utilisateurs doivent être avertis de ne pas le faire.

Ma position est qu'un utilisateur _mérite de savoir_ quand il fait une demande TLS qui n'est pas suffisamment sécurisée, en particulier dans tout système qui gère ses mots de passe.

Il y a un accord dans ce fil que nous devrions envisager d'avoir un crochet au niveau des requêtes pour désactiver ces avertissements. D'un autre côté, actuellement personne d'autre que vous ne pense qu'une distinction auparavant inexistante entre verify=False et verify=None devrait être ajoutée afin de faire taire implicitement ces avertissements. Vous trouverez qu'il est beaucoup plus facile de faire le premier que le second.

+1 pour ne pas faire la différence entre verify=False et verify=None. Je soutiendrais soit :

• ajouter un nouveau paramètre (par exemple, noInsecureWarnings), ou
• avoir des demandes intercepter l'avertissement urllib3 et émettre l'un des siens, donc (a) je peux supprimer quelque chose de moins effrayant que 'requests.packages.urllib3.exceptions.InsecureRequestWarning' (qui est déjà spécifique aux demandes de toute façon, mais se brisera si les demandes migrent vers une bibliothèque sous-jacente différente), et (b) l'avertissement peut pointer vers une URL spécifique aux requêtes (l'URL actuelle n'est pas pertinente car l'avertissement a été ombré !)

Et merci à tous les bénévoles d'avoir soutenu les demandes, que cela soit corrigé ou non : c'est une super bibliothèque :)

C'est une bibliothèque géniale, merci pour tout votre travail acharné.

J'ai rencontré ce problème après avoir récemment mis à niveau mes packages python et remarqué un grand nombre de nouvelles impressions InsecurePlatformWarning. Je contribue donc à mon cas d'utilisation, que je pense convaincant.

J'utilise des requêtes pour gérer les serveurs jenkins dans 4 environnements différents. Trois des environnements (dev, staging, production) ont tous des certificats valides. Le 4ème environnement est une boîte virtuelle vagabonde, que les développeurs peuvent utiliser pour tester les modifications sur leurs machines locales. Celui-ci n'a pas de certificat valide, mais en règle générale, toutes les configurations de serveur rejettent les demandes non cryptées.

Les paramètres de connexion jenkins (nom du serveur, jeton, etc.) pour un environnement incluent un indicateur spécifique pour désactiver la vérification SSL, qui n'est défini sur True que pour l'environnement vagrant.

Dans ma configuration, désactiver l'avertissement globalement serait une mauvaise idée car le projet est assez volumineux et de nombreuses requêtes peuvent être effectuées, avec ou sans la bibliothèque de requêtes. La désactivation de l'avertissement dans la portée serait bien, sauf qu'une partie du projet comprend une application de flacon et d'autres cas éventuellement multi-threads.

À mon avis, il semble que l'utilisation de verify=False devrait être prise en charge et fonctionner comme prévu, sans avertissements. C'est au développeur de l'application de décider quand et si cela doit être autorisé. Par exemple, si j'écrivais un navigateur pour un usage général, je ne définirais jamais ce paramètre sur True sans afficher une grande boîte de dialogue de confirmation avec beaucoup de texte en rouge. Mais si je possède le serveur et le client et que j'ai mes propres raisons pour ne pas émettre de certificat, je devrais pouvoir avoir un journal propre et ne pas cacher d'autres problèmes potentiels.

C'est au développeur de l'application de décider quand et si cela doit être autorisé.

C'est sur cette affirmation que je suis en désaccord avec vous. Je pense que c'est au développeur de décider quand il doit l'utiliser. Mais je crois que c'est à l'_utilisateur_ de décider si ce choix est acceptable. Il est _essentiel_ que les utilisateurs comprennent quand ils sont mis en danger par les choix des développeurs, et qu'ils soient en mesure d'évaluer ce risque.

Mais si je possède le serveur et le client et que j'ai mes propres raisons pour ne pas émettre de certificat, je devrais pouvoir avoir un journal propre et ne pas cacher d'autres problèmes potentiels.

Et vous pouvez le faire en utilisant un gestionnaire de contexte de journalisation pour capturer l'avertissement. Nous envisageons également de faire en sorte que les demandes rendent cet avertissement plus spécifique aux demandes afin qu'il soit plus facile à capturer, mais cela ne s'est pas encore produit.

J'ai une situation similaire à @jamie-sparked.

Je comprends l'intérêt de Lukasa pour renforcer la sécurité, mais je pense que vous devriez laisser VOTRE utilisateur décider de ce qui est le mieux pour lui.
Requests est une bibliothèque, pas une application d'utilisateur final. OMI, vous devriez considérer les développeurs comme vos utilisateurs.
Les développeurs d'applications devraient être responsables des erreurs de sécurité s'ils décident de désactiver la vérification du certificat (c'est-à-dire vérifier = False)

En tant que développeur, j'apprécie la flexibilité par rapport à une bibliothèque essayant de dicter ce que je dois faire.

BTW, comme d'autres l'ont dit, je trouve les demandes _excellentes_ et j'apprécie tous vos efforts. Merci.

@thalesac Nous laissons les développeurs décider. Comme discuté _plusieurs_ fois dans ce fil, il est tout à fait possible de désactiver cet avertissement. Cependant, nous n'avons pas un seul interrupteur qui désactive tous les avertissements : vous devez faire chacun manuellement. Il s'agit d'une tentative pour que nos utilisateurs retirent _consciemment_ chaque garde de sécurité.

Considérez-le comme une défense en profondeur. Pour utiliser une analogie avec une arme à pied, nous vous donnons une arme avec la sécurité et aucune balle dedans, et un chargeur. Si nous avions verify=False désactiver tous les avertissements, cela équivaudrait à avoir un pistolet qui, lorsqu'un chargeur était inséré, désactivait automatiquement la sécurité et chambrait une cartouche. Pratique? Sûr. Dangereux? Tu paries.

J'ai peur, je ne suis pas d'accord avec votre modèle d'analogie.
Je dirais verify=False EST votre mécanisme de sûreté/sécurité. Si vous l'avez désactivé explicitement (ou manuellement), vous ne voulez pas que le pistolet vous avertisse tout le temps lorsque vous tirez sur les méchants. De toute évidence, le comportement par défaut doit imposer une pensée de sécurité.
Quoi qu'il en soit, je comprends que ce n'est que mon point de vue et que vous devriez faire ce que vous pensez être le mieux pour votre projet. C'est peut-être pour ça que c'est une bonne bibliothèque. :)
Merci

Je suis tout à fait d'accord avec Lukasa, la sécurité est d'abord et si en tant que développeur j'utilise verify=False dans une partie de mon code, alors je devrais supprimer l'avertissement, si je ne veux pas être averti.

Quoi qu'il en soit excellente bibliothèque grand fan de votre travail d'équipe, continuez, +10000 pour la patience de nous répondre.

La façon dont je le vois, si une application utilise une URL définie par un utilisateur, l'utilisateur doit avoir la possibilité de désactiver la vérification, mais dans toutes les situations auxquelles je peux penser, il devrait recevoir l'avertissement. Si en tant que développeur et que vous savez pour quelle raison vous vous connectez à une URL qui ne devrait pas avoir de certificat valide (services internes pour lesquels vous ne paierez pas de certificat, test, etc.), vous devriez avoir la possibilité de désactiver les avertissements ainsi que la désactivation de la vérification.

Dans le même temps, je ne pense pas qu'il sera courant d'avoir une situation où vous voudriez désactiver les avertissements globalement en une seule fois, car cela rend trop facile l'ouverture de problèmes de sécurité qui sont ignorés en silence.

requests.packages.urllib3.disable_warnings() oui c'est du travail

salut

Est-ce que requests.packages.urllib3.disable_warnings() ne fonctionne plus ? il avait l'habitude de faire taire les avertissements pour moi. Voici où j'appelle la fonction de désactivation des avertissements, et voici un exemple de backtrace où la fonction d'avertissement est appelée :

 [+] Redirection acceptée vers 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()
 -> retour func()
 /usr/local/lib/python2.7/dist-packages/cement/core/controller.py(472)_dispatch()
 -> retour 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()
 -> en-têtes)
 /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()
 -> délai d'attente = délai d'attente
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(559)urlopen()
 -> corps=corps, en-têtes=en-têtes)
 /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((

Ce qui suit est le résultat de pip freeze , j'utilise les tests debian :

 argparse==1.2.1
 belle soupe4==4.4.1
 ciment==2.6.2
 charnet==2.3.0
 colorama==0.3.3
 couverture==4.0.3
 cryptographie==1.2.1
 distlib==0.2.1
 -e [email protected]:droope/droopescan.git@6524a9235e89a6fdb3ef304ee8dc4cb73eca0386#egg=droopescan-development
 enum34==1.1.2
 funcsigs==0.4
 contrats à terme==3.0.4
 html5lib==0.999
 httplib2==0.9.1
 idna==2.0
 adresseip==1.0.16
 lxml==3.5.0
 mercuriel==3.5.2
 simuler==1.3.0
 ndg-httpsclient==0.4.0
 nez==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
 rapportbug==6.6.6
 requêtes==2.9.1
 réponses==0,3.0
 réessayer==1.3.3
 six==1.10.0
 urllib3==1.13.1
 roue==0.26.0
 wsgiref==0.1.2

Merci,
Pedro

disable_warnings n'empêche pas l'appel de la fonction d'avertissement, il supprime simplement la sortie. Vous pouvez rencontrer des problèmes si un autre morceau de code active tous les avertissements.

Salut @Lukasa ,

J'ai mis le point d'arrêt après le si. En fin de compte, j'ai arrêté d'utiliser les tests debian car je rencontrais trop de problèmes, et cela pourrait très bien être l'un d'entre eux. J'ignorerais simplement mon commentaire, je ne suis pas sûr de ce qui s'est passé mais ce n'est probablement pas quelque chose qui affectera beaucoup de gens.

Merci!
Pierre

Oui, donc si vous utilisiez un paquet de Debian, il est possible que leur logique anti-fournisseur ait cassé quelque chose ici.

Vouloir faire une requête non sécurisée en spécifiant verify=False et ne pas voir d'avertissement pour cette requête, sans interférer avec les avertissements pour toute autre requête faite ailleurs semble parfaitement raisonnable.

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
...