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

Ich denke, Sie können diese auf globaler Ebene mit dem Modul warnings deaktivieren. Um mit der Protokollierung zu arbeiten (wenn ich mich richtig erinnere), müssen Sie außerdem in urllib3 greifen (und das dokumentieren wir), also bin ich nicht dagegen, dies für Benutzer zu dokumentieren, die keine Zertifikatsüberprüfung für HTTPS verwenden Verbindungen.

Ich bleibe nach wie vor dafür, diese Warnungen beizubehalten. Ja, sie sind nervig, aber sie sind auch aus einem bestimmten Grund da. Wenn überhaupt, bin ich versucht, es auszuschalten und durch eines unserer eigenen zu ersetzen! =P

An dieser Stelle ist es ziemlich offensichtlich, dass @Lukasa und ich bei dieser Funktion -1 sind. @kennethreitz @shazow irgendwelche

Bis zu einem gewissen Grad stimme ich zu, dass die Warnungen wichtig sind, aber ich denke, dass mehrere Faktoren berücksichtigt werden müssen.

Aus der Entwicklerperspektive wissen Sie, dass ich darüber Bescheid weiß. Ich kann dies einfach deaktivieren, wenn ich Lust dazu habe. Ich bin neuer bei Paketen, daher hat diese Lösung, als ich die Dokumente in der Warnung gelesen habe, nicht wirklich funktioniert. Ich mag die Idee, die @Lukasa präsentiert hat, um etwas zu machen, das spezifisch für requests .

Aus Benutzersicht habe ich heute pyvmomi mit pip installiert, das requests in seinen Interna verwendet. Es ist wirklich ein nicht transparenter Fehler, der an den Benutzer zurückgegeben wird, wenn requests eine stille unterstützende Bibliothek ist.

Ja, requests.packages.urllib3.disable_warnings() ist eine Verknüpfung zum Deaktivieren mithilfe der Filterung des Warnungsmoduls.

Ich würde dringend empfehlen, diesbezüglich eine Art Warnung zu haben. +0,5, wenn die urllib3 propagiert wird, +1, wenn Sie sich die Mühe machen und eine anfragespezifische hinzufügen möchten. -1 auf keine Warnung.

Wenn Sie möchten, können wir die urllib3-Warnmeldung konfigurierbar machen und Sie können sie überschreiben, damit Sie ansonsten dieselbe Logik verwenden können.

Auch hier halte ich diese Nachricht nicht für benutzerfeindlich, ich halte sie für äußerst wertvoll. Sie wissen jetzt, dass pyvmomi die TLS-Zertifikatsüberprüfung deaktiviert hat, was eine ziemlich wichtige Information ist!

Das heißt, ich habe nichts dagegen, dass wir mehr Anfragen haben, um es zum Schweigen zu bringen.

Ja, wirklich, ich denke, das ist ein Fehler in pyvmomi . Wenn sie sich nicht so schämen wollen, sollten sie Warnungen in ihrem Tool deaktivieren. Es ist nicht unsere Aufgabe, Benutzer _nicht_ zu warnen, dass die Verbindungen, die ein Tool herstellt, sie MITM-Angriffen aussetzen könnten, weil das Tool keine Zertifikatsüberprüfung durchführt.

Danke für die Diskussion Leute! Ich freue mich über jeden, der kommentiert und mir hilft, den Wert der Art und Weise, wie Dinge getan werden, und deren Gründe zu erkennen. Es fiel mir schwer, die allgemeineren Fälle zu sehen! :)

Wird heute an einem Patch arbeiten, wenn es die Zeit erlaubt, um eine "Anfrage-y"-Methode zum Schweigen zu haben. Rückmeldungen sind willkommen!

@invisiblethreat bei Fragen kannst du springen

Ich frage mich nur, ob Sie den Fall in Betracht gezogen haben, in dem Anforderungen in einem Webhook verwendet werden. Ich muss die Warnung unterdrücken, damit die JSON-Ausgabe des Skripts nicht verschmutzt wird (oder übersehe ich etwas?)

@macterra Ich bin mir nicht sicher, ob ich das verstehe. Suchen Sie nach alternativen Strategien zum Deaktivieren der Warnung oder ...?

Es ist mir auch äußerst unklar, warum Ihr Webhook die Zertifikatsüberprüfung deaktiviert. Das würde ich gerne lassen.

Wenn Sie stdout von einem Skript weiterleiten, um die Ergebnisse zu erhalten, werden Warnungen von stderr ausgegeben, damit sie Ihre JSON-Ausgabe nicht verschmutzen.

Richtig, wenn die Warnung auf stderr steht, dann kein Problem. Ich konnte es nicht erkennen, wenn ich mir die Ausgabe in der Konsole ansah, mein Fehler.

Ich denke, wir sollten dies anpassen, um auf die Anforderungsdokumentation statt auf die Dokumentation von urllib3 zu verweisen.

Ich bin mir nicht sicher, ob ich verstehe, was diese Warnfunktion erreichen soll und wie die Warnung gesteuert werden soll.

Ich habe ein Modul, das requests und Anfragen mit dem Argument verify=False . Dies führt dazu, dass die Benutzer meines Moduls die unnötige Warnung sehen. Unnötige Warnungen erschweren die Sichtbarkeit wichtiger Warnungen,

Es wäre für mein Modul sinnvoll, die Warnung zu deaktivieren, aber dann würde _ich die Warnung auch in jedem anderen Modul deaktivieren_ mit requests in der Anwendung!

Es ist nicht besser, wenn ich den Benutzer meines Moduls anweisen muss, die Warnung zu deaktivieren: Die Tatsache, dass ich requests ist normalerweise nur ein unsichtbares Implementierungsdetail, das der Benutzer nicht kennen sollte. Und der Benutzer hätte immer noch nur die Möglichkeit, alles zum Schweigen zu bringen oder zu notieren.

Ich glaube nicht, dass globale Warnungen hilfreich sein werden.

Ich könnte urllib3.HTTPSConnectionPool unterordnen und _validate_conn() überschreiben und requests dazu bringen, das in meinem Modul zu verwenden, um zu vermeiden, dass Warnungen von anderen Modulen ausgeblendet werden, aber das scheint zu viel Arbeit für eine einfache Sache zu sein .

Ich bin mir nicht sicher, ob ich verstehe, was diese Warnfunktion erreichen soll

bewirkt, dass die Benutzer meines Moduls die unnötige Warnung sehen.

Wenn Sie verify=False festlegen, sichern Sie Ihre Netzwerkverbindungen nicht mehr. Das ist IMHO _keine_ unnötige Warnung, sondern eine äußerst relevante Warnung. Ihre Benutzer, die zuvor keine Ahnung hatten, dass Sie keine Zertifikate verifizieren, wissen jetzt, dass dies wahr ist.

Wenn die Warnung für Ihr Modul nicht wertvoll ist, ist sie wahrscheinlich auch für kein anderes Modul in der Anwendung von Nutzen (sobald Sie die Sicherheit an einem Netzwerkpunkt weggeworfen haben, macht es keinen Sinn, überall anders darüber zu schreien). Ich sehe kein wirkliches Problem darin, es global zu deaktivieren.

Wenn der Benutzer explizit verify=False für eine bestimmte Anfrage anfordert, sehe ich den Wert einer Warnung nicht. Wenn ich als Modulautor verify=False setze, setze ich es auf Wunsch des Benutzers (oder ich bin bösartig, aber die Warnung hilft auch dort nicht, weil ich die Warnungen stumm schalten kann). Tatsächlich möchte ich vermeiden, bösartig zu sein und Warnungen nicht global stumm zu schalten, da dies die nützliche Warnung für diese Anfragen nimmt, die ein anderer Teil der Anwendung unwissentlich unsicher macht.

Wenn die Warnung für diejenigen Anforderungen aktiviert ist, bei denen die Überprüfung explizit durch den Benutzer deaktiviert wird, werden auch die Anforderungen ausgeblendet, bei denen der Benutzer die Warnung wünschen würde, da die Warnung nur einmal ausgegeben wird. Die Warnung ist für den Benutzer auch nicht wirklich hilfreich, da sie die URL der jeweiligen Anfrage nicht erwähnt.

Ich stimme nicht zu, dass das Wegwerfen der Sicherheit in einem Netzwerkpunkt irgendwie jegliche Sicherheitsüberprüfungen in der Anwendung nutzlos macht, ebenso wenig wie dies bei Browser-Herstellern der Fall ist. Mit Browsern kann ich Sicherheitsprüfungen für einzelne URLs umgehen, aber den Rest überprüfen, und das gefällt mir.

Wenn ich ein Tool habe, das mit einem internen Server mit einem selbstsignierten Zertifikat in einem internen Netzwerk kommuniziert, aber auch mit externen Hosts kommuniziert, möchte ich die externe Kommunikation überprüfen. Dies wäre die Situation, in der ich als Benutzer Warnungen zu versehentlich ungesicherten Anfragen sehen möchte.

Stellen Sie sich vor, ich verdiene service_foo und jemand verwendet es in einer App:

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)

Ich habe 2 Optionen für service_foo :

1. Ich lasse die globale Sicherheitswarnung eingeschaltet
   
   
   
   • Der Benutzer erhält immer eine Warnung, wenn die Anwendung mit https://10.0.0.1 spricht
   
   
   • Der Benutzer erhält nie eine Warnung, auch wenn die Anfrage an https://example.com/submit nicht sicher ist
   
   
2. Deaktivieren Sie die globale Sicherheitswarnung:
   
   
   
   • Der Benutzer erhält nie eine Warnung, selbst wenn die Anfrage an https://example.com/submit nicht sicher ist
   
   

Ich denke nicht, dass beide Optionen gut sind, aber Option 1 ist schlechter, weil sie Fehlalarme auslöst. Aber ich fühle mich nicht wohl, wenn die Sicherheitsprüfungen für den Benutzer als Nebeneffekt der Verwendung meines Moduls deaktiviert sind.

Wenn ich dies mit einem Shell-Skript tun würde, wäre der Benutzer glücklicher und sicherer:

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

Für mich macht es nur Sinn, eine Warnung auszugeben, wenn die Konfiguration der Python-Plattform defekt ist. Die Seite https://urllib3.readthedocs.org/en/latest/security.html, auf die in der InsecureRequestWarning Nachricht verlinkt wird, soll tatsächlich zeigen, wie Probleme in der Plattform behoben werden können. Wenn der Benutzer anfordert, die Überprüfung zu überspringen, sollte keine Warnung ausgegeben werden, wie wenn der Benutzer eine http URL anstelle einer https URL anfordert.

Wenn der Benutzer für eine bestimmte Anfrage ausdrücklich verify=False anfordert, wird der Wert einer Warnung nicht angezeigt.

Wer ist der „Benutzer“? Während Ihres gesamten Beitrags kam mir diese Frage immer wieder in den Sinn, weil ich glaube, dass Sie zwei Zielgruppen vermischen.

Wenn ich als Modulautor verifiziere=False setze, setze ich es auf Anfrage des Benutzers (oder ich bin bösartig).

Oder Sie sind fahrlässig. Sie haben sich von Benutzern beschwert, dass sie mit ihren selbstsignierten Zertifikaten nicht interoperieren konnten, und Sie haben die Zertifikatsüberprüfung deaktiviert, obwohl das Deaktivieren der Zertifikatsüberprüfung _nicht_ der richtige Weg ist, um dieses Problem zu lösen.

das nimmt die nützliche Warnung für diese Anfragen, die ein anderer Teil der Anwendung unwissentlich verunsichert

Dieser Satz verblüfft mich. Es deutet darauf hin, dass es akzeptabel ist, zu warnen, wenn eine Anwendung _unwissentlich_ unsichere Anforderungen stellt, aber dass eine Anwendung _wissentlich_, die sie stellt, irgendwie in Ordnung ist. Ich sehe nicht, wie das wissentliche Stellen unsicherer Anfragen in irgendeiner Weise als "sicherer" angesehen werden sollte, als dies unwissentlich zu tun.

Außerdem sollte die Warnung für Anfragen aktiviert sein, bei denen die Überprüfung vom Benutzer ausdrücklich deaktiviert wurde

Welcher Benutzer? Wie ist zwischen Modulautor und 'Benutzer' zu unterscheiden, wer auch immer sie sein mögen?

Die Warnung ist für den Benutzer auch nicht wirklich hilfreich, da sie die URL der jeweiligen Anfrage nicht erwähnt.

In der Warnung sollte die URL der Anfrage nicht erwähnt werden, da dies das Risiko von Warnungs-Spam verursachen würde. Wir warnen _einmal_ und sagen 'diese Anwendung ist gefährdet', nicht 'diese spezielle Kommunikation ist gefährdet'.

Mit Browsern kann ich Sicherheitsprüfungen für einzelne URLs umgehen, aber den Rest überprüfen, und das gefällt mir.

Browseranbieter _warnen_, wenn Sie auf eine URL mit einem ungültigen Zertifikat zugreifen! Sie drucken Dialogfelder und markieren die URL-Leiste rot! Das ist _genau_ das, was wir tun. Wir hindern Sie nicht daran, irgendetwas zu tun, wir sagen nur "Hey, das ist schlecht!" Was Sie von uns verlangen, ist dasselbe, als würden Sie Browseranbieter bitten, Benutzern zu erlauben, diese rote Warnung für bestimmte URLs zu deaktivieren, und ich garantiere, dass sie dies ablehnen werden, da die Sicherheitsauswirkungen monströs sind.

Wenn ich ein Tool habe, das mit einem internen Server mit einem selbstsignierten Zertifikat in einem internen Netzwerk kommuniziert, aber auch mit externen Hosts kommuniziert, möchte ich die externe Kommunikation überprüfen.

Nein, Sie möchten _alle_ die Kommunikation überprüfen. Überprüfen Sie das selbstsignierte Zertifikat! Bestätigen Sie, dass Sie das erwartete Zertifikat erhalten haben. verify=False sollte als Vorschlaghammer-Ansatz für Sicherheit betrachtet werden, der effektiv sagt: "Sicherheitsschraube, lass es einfach funktionieren". Das ist völlig in Ordnung, Sie haben das Recht, das zu sagen, aber wir sind verpflichtet, es als unsicher zu bezeichnen.

Ich denke nicht, dass beide Optionen gut sind, aber Option 1 ist schlechter, weil sie Fehlalarme auslöst.

Option 1 gibt keine Fehlalarme, sondern echte Alarme. Die Kommunikation zu 10.0.0.1 ist _unsicher_, und wir sollten nichts anderes vorgeben.

Wenn ich dies mit einem Shell-Skript tun würde, wäre der Benutzer glücklicher und sicherer.

Der Benutzer mag glücklicher sein, aber er wäre nicht sicherer. Sie wären genauso sicher wie zuvor. Sie scheinen den Eindruck zu haben, dass das Deaktivieren dieser Warnung auf magische Weise dazu führt, dass die Zertifikatsüberprüfung verschwindet, und das ist nicht der Fall. Ich werde am Ende dieser Antwort noch einmal darauf eingehen.

Für mich macht es nur Sinn, eine Warnung auszugeben, wenn die Konfiguration der Python-Plattform defekt ist.

Nein, wir sollten hart scheitern, wenn die Konfiguration der Python-Plattform defekt ist und Sie nicht nach ungeprüften Anfragen gefragt haben. Wenn Ihre Plattform keine sicheren TLS-Verbindungen herstellen kann, sollten wir sie auf keinen Fall herstellen, es sei denn, unser Benutzer weist uns ausdrücklich an, dass wir uns nicht darum kümmern sollen (indem wir verify=False ). In diesem Fall sollten wir Sie warnen zu tun sind, ist gefährlich.

Ich glaube, Sie haben ein Missverständnis, daher möchte ich etwas ganz klar sagen: Es gibt keine Möglichkeit, eine nicht validierte HTTPS-Anfrage mit Anfragen zu stellen, ohne entweder a) verify=False (unser Warnverhalten) festzulegen oder b) das Modul ssl absichtlich sabotieren. Wir können b) nicht fangen und warnen nicht davor. Dies ist die einzige Situation, die unter den von Ihnen angesprochenen Begriff "Probleme mit der Plattform" fallen würde. Die Ratschläge auf der Hilfeseite von urllib3 gelten nicht für uns, da wir alle erforderlichen plattformbezogenen Schritte unternehmen, einschließlich der Bündelung vertrauenswürdiger Zertifikate und der manuellen Überprüfung von Zertifikaten.

In der Web-Community herrscht die gefährliche Ansicht, dass Sie nur Zertifikate überprüfen sollten, die von vertrauenswürdigen Stammzertifikaten signiert wurden. Diese Ansicht ist völlig fehlgeleitet. Wenn Sie auf selbstsignierte Zertifikate stoßen, sollten Sie sie verdammt noch mal validieren. Das ist absolut machbar! Fügen Sie das selbstsignierte Zertifikat einer .pem Datei hinzu und übergeben Sie es als Argument an verify !

Wenn Sie Schwierigkeiten haben, dies mit der gebündelten .pem Datei zu kombinieren, lassen Sie es mich bitte wissen und ich werde mkcert.org verbessern, damit Sie Ihre eigenen Zertifikate mit den vertrauenswürdigen Roots verketten können. Aber bitte tun Sie nicht so, als wäre die Einstellung von verify=False sicher: Das ist es einfach nicht.

Wenn die Warnung für diejenigen Anforderungen aktiviert ist, bei denen die Überprüfung explizit durch den Benutzer deaktiviert wird, werden auch die Anforderungen ausgeblendet, bei denen der Benutzer die Warnung wünschen würde, da die Warnung nur einmal ausgegeben wird.

Das ist auch etwas rätselhaft. Indem Sie verify=False festlegen, deaktivieren Sie es möglicherweise explizit für genau diese Anfrage, aber es gibt keine Möglichkeit, dies über den Punkt hinaus zu vermitteln, an dem wir unsere Anfrage erstellen. Es gibt auch keinen Grund, es über diesen Punkt hinaus zu übermitteln, da Sie die Zertifikatsüberprüfung deaktiviert haben. Der Kontext, in dem Sie dies getan haben, hat für uns oder andere Nutzer Ihrer App keine Bedeutung.

Was Sie von uns verlangen, ist dasselbe, als würden Sie Browseranbieter bitten, Benutzern zu erlauben, diese rote Warnung für bestimmte URLs zu deaktivieren, und ich garantiere, dass sie dies ablehnen werden, da die Sicherheitsauswirkungen monströs sind.

Meine Browser erlauben es mir, ein ungeprüftes Zertifikat dauerhaft zu akzeptieren, das "ungeheuerlich unsicher" ist.

Die Kommunikation zu 10.0.0.1 ist unsicher, und wir sollten nichts anderes vorgeben.

Die Verbindung ist insofern unsicher, als Sie ein digitales Zertifikat nicht überprüfen können, aber die Überprüfung eines Zertifikats sagt Ihnen nicht wirklich, ob der Server, mit dem Sie sprechen, sicher ist. Aber wenn ich mit einem Server in einem geschlossenen Netzwerk spreche, kann ich die Sicherheit des Servers wirklich sicherstellen.

Ich glaube, Sie arbeiten an einem Missverständnis, daher möchte ich etwas ganz klar sagen: Es gibt keine Möglichkeit, eine nicht validierte HTTPS-Anfrage mit Anfragen zu stellen, ohne entweder a) Verify=False (unser Warnverhalten) oder b) absichtlich zu setzen die SSL sabotieren

Ich frage mich, wie ich ein guter Bürger in meinem Modul sein kann, indem ich dem Wunsch des Benutzers nachkomme, Zertifikatsprüfungen und Warnungen für die URL zu ignorieren, die sie mir geben. Und welchen Mehrwert das Warnmodell bietet. Was ist der Fall, wenn eine Anfrage mit verify=False dem Benutzer eine Warnung anzeigen soll?

Ich sehe nicht, wie der Warnmechanismus fahrlässigen Code abfangen kann, da er nicht unterscheiden kann, ob eine Anfrage wegen schlampiger Codierung erfolgt oder weil ein Benutzer dies angefordert hat. Ich glaube auch nicht, dass ein Modul wie requests eine Sicherheitsrichtlinie diktieren sollte. Ich habe verstanden, dass Warnungen normalerweise an Entwickler gerichtet sind, damit sie falschen Code korrigieren können, aber diese Warnung ist nicht so. Wenn die Warnung nur zur allgemeinen Aufklärung des Benutzers dient, sollte es für den Benutzer eine einfache Möglichkeit geben, sie auszublenden.

Die Warnung ist auch nicht nur kosmetisch, weil sie die Ausgabe eines Programms durcheinander bringt.

Ich sehe nur einen negativen Wert der Warnung, also schalte ich sie in meinem Modul aus, auch wenn ich es hasse, eine solche globale Richtlinienänderung dort zu verbergen.

In der Web-Community herrscht die gefährliche Ansicht, dass Sie nur Zertifikate überprüfen sollten, die von vertrauenswürdigen Stammzertifikaten signiert wurden. Diese Ansicht ist völlig fehlgeleitet.

Wusste nicht, dass es so eine Ansicht gibt. Ein von einem Root-Zertifikat signiertes Zertifikat beweist nicht wirklich etwas über die Sicherheit der Site. Es ist billig, ein anonymes Zertifikat zu erhalten, wenn Sie schlechte Dinge tun möchten.

Wenn Sie auf selbstsignierte Zertifikate stoßen, sollten Sie sie verdammt noch mal validieren. Das ist absolut machbar! Fügen Sie das selbstsignierte Zertifikat einer .pem-Datei hinzu und übergeben Sie es als Argument zur Überprüfung!

Der Benutzer würde einen sicheren Kanal benötigen, um das Zertifikat zu erhalten, wie ein internes vertrauenswürdiges Netzwerk. Aber wenn sich der Server selbst im gleichen internen Netzwerk befindet, ist nicht viel gewonnen. Aber das entscheidet auf jeden Fall der Benutzer, ich kann in meinem Modul keine Richtlinie auferlegen.

Ich stimme @kankri größtenteils zu. Das war die ursprüngliche Designabsicht.

Ich schlage etwas vor – das wir standardmäßig deaktivieren, aber unsere eigene Funktion haben, um es wieder zu aktivieren oder zu dokumentieren, wie es eingeschaltet wird. Ich möchte nicht, dass Benutzer den Code wie beabsichtigt verwenden müssen. verify=False ist ein Feature, wenn auch kein Best-Practice-Feature. Das geht uns nichts an.

Ich stimme zu, dass verify=False eine Funktion ist, aber ich stimme nicht zu, dass es sich um eine Funktion auf derselben Ebene wie params= oder cert= . Es ist eine Funktion, die standardmäßig auf einen sicheren Wert eingestellt ist und auf einen unsicheren Wert eingestellt werden kann. Es ist eine riesige, verlockende Option für die Leute, Sicherheit aus Gründen der Zweckmäßigkeit aus dem Fenster zu werfen, und ich denke, diesem Impuls sollte man widerstehen (aber nicht verbieten). Ich werde immer zu der Denkweise "Sie müssen explizit unsicher sein" tendieren, und es ist mir egal, ob das bedeutet, zwei Schalter umzulegen und nicht einen.

Egal, das ist Ihr Anruf, nicht meiner. =)

Wollte nur sagen, dass ich @kennethreitz zustimme

Verify=False ist ein Feature, wenn auch kein Best-Practice-Feature. Das geht uns nichts an.

fasst es gut zusammen.

Für diejenigen, die auch die Warnungen deaktivieren möchten, ist dies der Fall. Sie müssen die Warnungsmodule verwenden , die Teil der Standardbibliothek sind:

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)

Dies konfiguriert einen Warnungsfilter, der jede Warnung der Kategorie InsecureRequestWarning ignoriert. Die Ausgabe sieht wie folgt aus:

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

(Die Test-Site gibt zufällig eine 403-Forbidden-Seite zurück, aber das ist hier nicht wichtig.)

Beachten Sie, dass Sie die Klasse aus dem gebündelten urllib3 Paket verwenden müssen und nicht die Klasse aus einem urllib3 Paket der obersten Ebene, falls Sie eines installiert haben.

Sie können (und sollten wahrscheinlich) eine kleine Funktion erstellen, die den Kontextmanager im kleinstmöglichen Codebereich verwendet:

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

Oder tun Sie einfach dies:

requests.packages.urllib3.disable_warnings()

@Lukasa

Oder tun Sie einfach dies:

requests.packages.urllib3.disable_warnings()

Abgesehen davon, dass ich im Anforderungshandbuch keine Erwähnung dieser Funktion finde.

Obwohl es bei weitem nicht jeder ist, der sich damit auskennt, würde ich argumentieren, dass das warnings Modul das Standardwerkzeug ist, auf das ein Python-Programmierer achten sollte, wenn er Warnungen deaktivieren möchte. Es ist Teil der Standardbibliothek und gut dokumentiert.

Ich schlage vor, einen Verweis auf warnings in die requests -Dokumentation aufzunehmen – oder auf die bequeme disable_warnings Funktion, solange es ein entsprechendes enable_warnings Funktion ( so eine Funktion scheint es nicht zu geben ).

Nochmals: Ich möchte Warnungen nicht generell deaktivieren. Ich möchte nur, dass diese spezielle Warnung verschwindet, wenn ich in meinem Code _explizit_verify=False setze. Es kann andere, nützliche Warnungen geben, im Gegensatz zu dieser speziellen, nutzlosen Warnung. Was ist daran so schwer zu verstehen?!

@zaitcev Auf die Gefahr hin, mich zu wiederholen:

requests.packages.urllib3.disable_warnings()

Und wenn Ihnen selbst das zu weit gefasst ist:

from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

Zum Schluss noch eine Anmerkung, @zaitcev : Sie werden feststellen, dass Ihnen der verärgerte Ton, den Sie gerade gegeben haben, keinen Gefallen

@zaitcev Es sieht nicht so aus, als würde sich dies im Request-Modul selbst ändern, aber ich hoffe, Sie können den Code verwenden, den ich in meinen anderen Kommentar eingefügt habe . Das sollte es Ihnen ermöglichen, die von urllib3 ausgegebenen Warnungen selektiv zu deaktivieren.

Sie können es auch unterdrücken mit:

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

In meinem Fall verwende ich Anfragen nicht direkt, daher kann ich mir durch das Unterdrücken dieser Art weniger Sorgen machen, dass ich später kaputt gehen könnte.

@zaitcev Wenn Sie alle vorherigen Vorschläge zusammenfassen, können Sie

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 Das würde Warnungen für alle nachfolgenden Anfragen deaktiviert lassen.

Wenn ich andere Beispiele zusammengestellt habe, habe ich den Standardwert Session (da requests.get und andere Verknüpfungen sowieso ein temporäres Session erstellen):

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)

Alle Warnungen von requests deaktivieren ist wahrscheinlich eine schlechte Idee, ein bisschen besser könnte sein:

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

Um zusammenzufassen, wie ich damit umgegangen bin:

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

Dadurch kann ich überprüfen, ob eine Anfrage unsicher ist, die URL-Warnung ausblenden und eine Warnung vor meiner eigenen Formatierung für den Benutzer ausgeben. Es erfordert, dass die Anfrage zweimal gestellt wird. Bearbeitet, um die Ausnahmeklausel weniger breit zu machen.

except Exception: ist SEHR breit gefächert. das willst du wirklich nicht.

Das Obige trägt in gewisser Weise dazu bei, die Bedenken auf beiden Seiten dieser Diskussion auszuräumen.

wirft es nicht eine Unterklasse von Exception, die Sie stattdessen abfangen können?

Oder verwenden Sie logging.captureWarnings()

Die Alternative besteht darin, zu wissen, dass urllib3 beteiligt ist, und seinen Namensraum fest zu codieren, siehe Kommentar von tuukkamustonen. Dies war mein Haupteinwand: Sie hätten es richtig machen können, ich habe sogar einen Patch in einem Pull-Request bereitgestellt. Aber sie leugnen, dass das Problem existiert und sagen allen Benutzern, dass sie schreckliche Problemumgehungen wie "außer Ausnahme" oder "von Requests.packages.urllib3-Importausnahmen" finden sollen. An diesem Punkt muss jemand zugeben, dass er sich die ganze Zeit geirrt hat und so stecken wir fest.

Dies war mein Haupteinwand: Sie hätten es richtig machen können, ich habe sogar einen Patch in einem Pull-Request bereitgestellt. Aber sie leugnen, dass das Problem existiert und sagen allen Benutzern, dass sie schreckliche Problemumgehungen wie "außer Ausnahme" oder "von Requests.packages.urllib3-Importausnahmen" finden sollen. An diesem Punkt muss jemand zugeben, dass er sich die ganze Zeit geirrt hat und so stecken wir fest.

@zaitcev Lassen Sie mich noch einmal daran erinnern, dass dies eine Freiwilligengemeinschaft ist, die ihr Bestes gibt. Wir haben dieses Thema zur Diskussion freigelassen, wir haben nicht versucht, es zu sperren oder weitere Diskussionen zu verhindern. Wir _hören Ihnen zu_. Was wir nicht tun, ist, Ihrer Einschätzung der Situation sofort zuzustimmen. Bitte bedenken Sie die Möglichkeit, dass wir uns um mehr Anwendungsfälle kümmern als nur um Ihre und dass wir die Bedürfnisse aller abwägen müssen.

Ihr Pull-Request wurde aus einem _sehr spezifischen Grund_ abgelehnt, den Sie ständig ignorieren! Lassen Sie mich mich ich Ian zitiere:

Die Schlusserklärung lautete: "Da dies hauptsächlich in urllib3 ist und dort auf Akzeptanz angewiesen wäre, schließe ich dies, bis dort Fortschritte erzielt wurden

Bis heute sehe ich in urllib3 immer noch keinen zugehörigen Pull-Request oder kein Problem für dieses Problem. Niemand von diesem Projekt hat Ihnen im Weg gestanden oder diese Arbeit verhindert, wir haben uns einfach nicht dafür entschieden, es selbst zu tun, weil _wir derzeit nicht mit Ihnen einverstanden sind_.

Auf die Gefahr hin, wieder in dieses Kaninchenloch zu gehen, möchte ich jedoch wiederholen:

Das war mein Haupteinwand: Sie hätten es richtig machen können.

Ich glaube nicht, dass Ihr Patch diese Funktion "richtig" macht . Wie ich in diesem Thread schon oft gesagt habe, halte ich das aktuelle Verhalten für wünschenswert. Es ist eine schlechte Idee, unsichere TLS-Anforderungen durchzuführen, und Benutzer sollten davor gewarnt werden.

Meine Position ist, dass ein Benutzer es _verdient zu wissen_, wenn er eine TLS-Anfrage stellt, die nicht ausreichend gesichert ist, insbesondere in jedem System, das seine Passwörter verarbeitet.

In diesem Thread herrscht verify=False und verify=None hinzugefügt werden sollte, um diese Warnungen implizit zum Schweigen zu bringen. Sie werden feststellen, dass Ersteres viel einfacher ist als Letzteres.

+1, um nicht zwischen verifizieren=False und verifizieren=None zu unterscheiden. Ich würde entweder unterstützen:

• Hinzufügen eines neuen Parameters (sagen wir noInsecureWarnings) oder
• Wenn Anfragen die urllib3-Warnung abfangen und eine eigene ausgeben, kann ich (a) etwas weniger Beängstigendes unterdrücken als 'requests.packages.urllib3.Exceptions.InsecureRequestWarning' (das ohnehin schon anfragespezifisch ist, aber abbricht, wenn Anfragen migriert werden) zu einer anderen zugrunde liegenden Bibliothek), und (b) die Warnung kann auf eine anfragespezifische URL verweisen (die aktuelle URL ist nicht relevant, da die Warnung schattiert wurde!)

Und danke an alle Freiwilligen für die Unterstützung von Anfragen, egal ob dies behoben wird oder nicht: Es ist eine großartige Bibliothek :)

Dies ist eine großartige Bibliothek, vielen Dank für Ihre harte Arbeit.

Ich bin auf dieses Problem gestoßen, nachdem ich kürzlich meine Python-Pakete aktualisiert und eine Reihe neuer InsecurePlatformWarning-Ausdrucke bemerkt habe. Also trage ich meinen Anwendungsfall bei, den ich für überzeugend halte.

Ich verwende Anfragen, um Jenkins-Server in 4 verschiedenen Umgebungen zu verwalten. Drei der Umgebungen (Entwicklung, Staging, Produktion) verfügen alle über gültige Zertifikate. Die vierte Umgebung ist eine vagabundierende virtuelle Box, mit der Entwickler Änderungen auf ihren lokalen Maschinen testen können. Dieser hat kein gültiges Zertifikat, aber grundsätzlich lehnen alle Serverkonfigurationen unverschlüsselte Anfragen ab.

Die Jenkins-Verbindungseinstellungen (Servername, Token usw.) für eine Umgebung enthalten ein spezielles Flag zum Deaktivieren der SSL-Überprüfung, das nur für die vagabundierende Umgebung auf True gesetzt ist.

In meinem Setup wäre es eine schlechte Idee, die Warnung global zu deaktivieren, da das Projekt ziemlich groß ist und viele Anfragen gestellt werden können, mit oder ohne die Anfragebibliothek. Das Deaktivieren der Warnung im Umfang wäre in Ordnung, es sei denn, ein Teil des Projekts umfasst eine Kolbenanwendung und andere möglicherweise mehrfädige Fälle.

Meiner Meinung nach sollte die Verwendung von verify=False unterstützt werden und wie erwartet ohne Warnungen funktionieren. Es liegt im Ermessen des Anwendungsentwicklers, wann und ob dies zulässig ist. Wenn ich beispielsweise einen Browser für den allgemeinen Gebrauch schreibe, würde ich dies niemals auf True setzen, ohne einen großen Bestätigungsdialog mit viel rotem Text anzuzeigen. Aber wenn ich den Server und den Client besitze und meine eigenen Gründe habe, kein Zertifikat auszustellen, sollte ich in der Lage sein, ein sauberes Protokoll zu haben und andere potenzielle Probleme nicht zu verbergen.

Es liegt im Ermessen des Anwendungsentwicklers, wann und ob dies zulässig ist.

Bei dieser Behauptung bin ich anderer Meinung als Sie. Ich glaube, es liegt am Entwickler, zu entscheiden, wann er es verwenden soll. Aber ich glaube, es liegt am _Benutzer_ zu entscheiden, ob diese Wahl akzeptabel ist. Es ist _kritisch_, dass die Benutzer verstehen, wann sie durch die Entscheidungen der Entwickler einem Risiko ausgesetzt sind, und dass sie dieses Risiko einschätzen können.

Aber wenn ich den Server und den Client besitze und meine eigenen Gründe habe, kein Zertifikat auszustellen, sollte ich in der Lage sein, ein sauberes Protokoll zu haben und andere potenzielle Probleme nicht zu verbergen.

Und Sie können dies tun, indem Sie einen Protokollierungskontextmanager verwenden, um die Warnung zu erfassen. Wir erwägen auch, diese Warnung auf Anfragen spezifischer zu machen, damit sie leichter erfasst werden kann, aber das ist noch nicht geschehen.

Ich habe eine ähnliche Situation wie @jamie-sparked.

Ich verstehe den Standpunkt von Lukasa zur Durchsetzung der Sicherheit, aber ich denke, Sie sollten IHREN Benutzer entscheiden lassen, was für ihn am besten ist.
Requests ist eine Bibliothek, keine Endbenutzeranwendung. IMO sollten Sie Entwickler als Ihre Benutzer betrachten.
Anwendungsentwickler sollten für Sicherheitsfehler haftbar gemacht werden, wenn sie sich entscheiden, die Zertifikatsüberprüfung abzuschalten (dh verifizieren=False)

Als Entwickler schätze ich Flexibilität mehr als eine Bibliothek, die mir vorschreibt, was ich tun soll.

Übrigens, wie andere schon sagten, finde ich Anfragen _ausgezeichnet_ und schätze all Ihre Bemühungen. Vielen Dank.

@thalesac Wir _do_ lassen Entwickler entscheiden. Wie in diesem Thread _oft_ besprochen, ist es durchaus möglich, diese Warnung auszuschalten. Wir haben jedoch keinen Schalter, der alle Warnungen ausschaltet: Sie müssen jede einzelne manuell ausführen. Dies ist ein Versuch, unsere Benutzer _bewusst_ dazu zu bringen, jede Schutzvorrichtung zu entfernen.

Betrachten Sie es als Tiefenverteidigung. Um eine Analogie mit einer Fußkanone zu verwenden, geben wir Ihnen eine Waffe mit Sicherung und ohne Kugeln und ein Magazin. Wenn wir verify=False alle Warnungen deaktivieren müssten, wäre das gleichbedeutend mit einer Waffe, die beim Einlegen eines Magazins automatisch die Sicherung deaktiviert und eine Patrone geschossen hat. Praktisch? Sicher. Gefährlich? Sie wetten.

Ich fürchte, ich stimme Ihrem Analogiemodell nicht zu.
Ich würde sagen verify=False IST Ihr Sicherheitsmechanismus. Wenn Sie es explizit (oder manuell) deaktiviert haben, möchten Sie nicht, dass die Waffe Sie die ganze Zeit warnt, wenn Sie die Bösen erschießen. Offensichtlich muss das Standardverhalten Sicherheitsdenken erzwingen.
Wie auch immer, ich verstehe, dass dies nur meine Ansicht ist und Sie sollten das tun, was Sie für Ihr Projekt am besten halten. Vielleicht ist es deshalb eine gute Bibliothek. :)
Vielen Dank

Ich stimme Lukasa definitiv zu, Sicherheit steht an erster Stelle und wenn ich als Entwickler in einem Teil meines Codes verify=False verwende, sollte ich die Warnung unterdrücken, wenn ich nicht gewarnt werden möchte.

Wie auch immer, ausgezeichnete Bibliothek, großer Fan Ihrer Teamarbeit, machen Sie weiter so, +10000 für die Geduld, uns zu antworten.

So wie ich es sehe, sollte eine Anwendung, die eine von einem Benutzer festgelegte URL verwendet, dem Benutzer eine Option zum Deaktivieren der Überprüfung zur Verfügung gestellt werden, aber in jeder Situation, die mir einfällt, sollten sie die Warnung erhalten. Wenn Sie als Entwickler wissen, aus welchem ​​​​Grund auch immer Sie eine Verbindung zu einer URL herstellen, von der erwartet wird, dass sie kein gültiges Zertifikat hat (interne Dienste, für die Sie kein Zertifikat bezahlen, Tests usw.), dann sollten Sie die Option zum Deaktivieren haben die Warnungen zusammen mit dem Deaktivieren der Überprüfung.

Gleichzeitig glaube ich nicht, dass es üblich ist, eine Situation zu haben, in der Sie die Warnungen auf einmal global deaktivieren möchten, da dies es zu einfach macht, Sicherheitsprobleme zu öffnen, die stillschweigend ignoriert werden.

requests.packages.urllib3.disable_warnings() ja es funktioniert

Hi

Funktioniert requests.packages.urllib3.disable_warnings() nicht mehr? es hat die Warnungen für mich zum Schweigen gebracht. Hier rufe ich die Funktion zum Deaktivieren von Warnungen auf, und hier ist ein Beispiel für eine Rückverfolgung, bei der die Warnungsfunktion aufgerufen wird:

 [+] Akzeptierte Weiterleitung zu https://drupal.org/
 > /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(791)_validate_conn()
 -> warnungen.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()
 -> Rückgabefunktion()
 /usr/local/lib/python2.7/dist-packages/cement/core/controller.py(472)_dispatch()
 -> Rückgabefunktion()
 /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()
 -> Überschriften)
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py(827)enumerate_file_hash()
 -> r = self.session.get(url + file_url, timeout=timeout, headers=header)
 /usr/lib/python2.7/dist-packages/requests/sessions.py(480)get()
 -> Rückgabe 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(Anfrage, **kwargs)
 /usr/lib/python2.7/dist-packages/requests/adapters.py(376)send()
 -> Zeitüberschreitung=Zeitüberschreitung
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(559)urlopen()
 -> body=body, headers=header)
 /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()
 -> warnungen.warn((

Das Folgende ist die Ausgabe von pip freeze , ich verwende Debian-Tests:

 argparse==1.2.1
 schönesuppe4==4.4.1
 Zement==2.6.2
 chardet==2.3.0
 colorama==0.3.3
 Abdeckung==4.0.3
 Kryptographie==1.2.1
 distlib==0.2.1
 -e [email protected]:droope/droopescan.git@6524a9235e89a6fdb3ef304ee8dc4cb73eca0386#egg=droopescan-development
 enum34==1.1.2
 Funksigs==0.4
 Futures==3.0.4
 html5lib==0.999
 httplib2==0.9.1
 idna==2.0
 IP-Adresse==1.0.16
 lxml==3.5.0
 Quecksilber==3.5.2
 Schein==1.3.0
 ndg-httpsclient==0.4.0
 Nase==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
 Fehler melden==6.6.6
 Anfragen==2.9.1
 Antworten==0,3.0
 erneut versuchen==1.3.3
 sechs==1.10.0
 urllib3==1.13.1
 Rad==0.26.0
 wsgiref==0,1.2

Vielen Dank,
Pedro

disable_warnings verhindert nicht den Aufruf der Warnfunktion, sondern unterdrückt lediglich die Ausgabe. Es können Probleme auftreten, wenn ein anderer Code alle Warnungen aktiviert.

Hallo @Lukasa ,

Ich setze den Breakpoint nach dem if. Am Ende habe ich aufgehört, Debian-Tests zu verwenden, da ich auf zu viele Probleme gestoßen bin, und dies könnte sehr gut eines davon sein. Ich würde meinen Kommentar einfach ignorieren, ich bin mir nicht sicher, was passiert ist, aber es wird wahrscheinlich nicht viele Leute betreffen.

Vielen Dank!
Pedro

Ja, wenn Sie also ein Paket von Debian verwenden, ist es möglich, dass ihre Nichtverkaufslogik hier etwas kaputt gemacht hat.

Der Wunsch, eine unsichere Anfrage durch Angabe von verify=False und keine Warnung für diese Anfrage zu sehen, ohne die Warnungen für andere an anderer Stelle gestellte Anfragen zu stören, scheint völlig vernünftig.

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