Requests: verifikasi=Salah dan request.packages.urllib3.disable_warnings()

Saya pikir Anda dapat menonaktifkan ini di tingkat global dengan modul warnings . Selanjutnya, untuk bekerja dengan logging (jika saya ingat dengan benar) Anda perlu mencapai urllib3 (dan kami mendokumentasikannya), jadi saya tidak menentang mendokumentasikan ini untuk pengguna yang tidak akan menggunakan verifikasi sertifikat untuk HTTPS koneksi.

Saya tetap sangat mendukung untuk meninggalkan peringatan ini di tempat. Ya, mereka menjengkelkan, tetapi mereka juga ada karena suatu alasan. Jika ada, saya tergoda untuk mematikannya dan menggantinya dengan salah satu milik kami! =P

Pada titik ini cukup jelas bahwa @Lukasa dan saya -1 pada fitur ini. @kennethreitz @shazow ada pendapat?

Sampai batas tertentu, saya setuju bahwa peringatan itu penting, tetapi saya pikir ada banyak faktor yang mungkin perlu dipertimbangkan.

Dari perspektif pengembang, ketahuilah bahwa saya tahu tentang ini, saya bisa mematikannya jika saya ingin. Saya lebih baru dalam paket, jadi ketika saya membaca dokumen, dalam peringatan, solusi itu tidak benar-benar berfungsi. Saya suka ide yang disampaikan @Lukasa tentang membuat sesuatu yang spesifik untuk requests .

Dari sudut pandang pengguna, saya menginstal pyvmomi dengan pip hari ini, yang menggunakan requests di internalnya. Ini benar-benar kesalahan non-transparan yang dipancarkan kembali ke pengguna dalam kasus di mana requests adalah pustaka pendukung diam.

Ya, requests.packages.urllib3.disable_warnings() adalah jalan pintas untuk mematikannya menggunakan pemfilteran modul peringatan.

Saya sangat merekomendasikan memiliki semacam peringatan untuk efek ini. +0,5 tentang memiliki urllib3 yang disebarkan, +1 jika Anda ingin berusaha dan menambahkan permintaan khusus. -1 karena tidak memiliki peringatan.

Jika Anda mau, kami dapat membuat pesan peringatan urllib3 dapat dikonfigurasi dan Anda dapat menimpanya sehingga Anda dapat mendukung logika yang sama jika tidak.

Sekali lagi, saya tidak menganggap pesan ini memusuhi pengguna, saya menganggapnya sangat berharga. Anda sekarang tahu bahwa pyvmomi telah mematikan verifikasi sertifikat TLS, yang merupakan informasi yang cukup penting!

Yang mengatakan, saya tidak keberatan kami memiliki lebih banyak permintaan-y cara untuk membungkamnya.

Ya, sungguh saya pikir ini adalah bug di pyvmomi . Jika mereka tidak ingin dipermalukan seperti ini, mereka harus menonaktifkan peringatan di alat mereka. Bukan tugas kami untuk _tidak_ memperingatkan pengguna bahwa koneksi yang dibuat oleh beberapa alat dapat membuat mereka terkena serangan MITM karena alat tersebut tidak melakukan verifikasi sertifikat.

Terima kasih untuk diskusi orang-orang! Saya menghargai semua orang yang berkomentar, dan membantu saya melihat nilai dalam cara melakukan sesuatu, dan mengapa. Saya mengalami kesulitan melihat kasus yang lebih umum! :)

Akan bekerja pada tambalan hari ini, jika waktu memungkinkan, untuk memiliki cara 'permintaan-y' untuk diam. Umpan balik akan diterima!

@invisiblethreat jangan ragu untuk masuk ke IRC jika Anda memiliki pertanyaan

Hanya ingin tahu apakah Anda mempertimbangkan kasus di mana permintaan digunakan di webhook. Saya harus menekan peringatan agar tidak mencemari output JSON dari skrip (atau apakah saya melewatkan sesuatu?)

@macterra Saya tidak yakin saya mengerti. Apakah Anda mencari strategi alternatif untuk menonaktifkan peringatan atau ...?

Juga sangat tidak jelas bagi saya mengapa webhook Anda menonaktifkan verifikasi sertifikat. Saya ingin meninggalkan itu.

Selanjutnya, jika Anda mem-pipe stdout dari beberapa skrip untuk mendapatkan hasilnya, peringatan akan keluar dari stderr sehingga seharusnya tidak mencemari output JSON Anda.

Benar, jika peringatan ada di stderr maka tidak masalah. Saya tidak tahu dari melihat output di konsol, kesalahan saya.

Saya pikir kita harus menyesuaikan ini untuk menunjuk ke dokumentasi permintaan alih-alih dokumentasi urllib3.

Saya tidak yakin saya mengerti apa yang dimaksudkan untuk dicapai oleh fitur peringatan ini dan bagaimana peringatan itu dimaksudkan untuk dikontrol.

Saya memiliki modul yang menggunakan requests dan harus membuat permintaan dengan argumen verify=False . Ini menyebabkan pengguna modul saya melihat peringatan yang tidak perlu. Peringatan yang tidak perlu membuat peringatan penting lebih sulit dilihat,

Masuk akal jika modul saya menonaktifkan peringatan, tetapi kemudian _Saya juga akan menonaktifkan peringatan di modul lain_ menggunakan requests dalam aplikasi!

Hal-hal tidak lebih baik jika saya perlu menginstruksikan pengguna modul saya untuk menonaktifkan peringatan: Fakta bahwa saya menggunakan requests biasanya hanya detail implementasi yang tidak terlihat yang tidak perlu diketahui pengguna. Dan pengguna masih hanya memiliki opsi untuk membungkam semuanya atau mencatat.

Saya tidak berpikir peringatan global akan membantu.

Saya dapat mensubklasifikasikan urllib3.HTTPSConnectionPool dan menimpa _validate_conn() dan membuat requests menggunakannya dalam modul saya untuk menghindari menyembunyikan peringatan dari modul lain, tetapi itu tampaknya terlalu banyak bekerja untuk hal yang sederhana .

Saya tidak yakin saya mengerti apa yang ingin dicapai oleh fitur peringatan ini

menyebabkan pengguna modul saya melihat peringatan yang tidak perlu.

Saat Anda menyetel verify=False Anda tidak lagi mengamankan koneksi jaringan Anda. Itu, IMHO, adalah _not_ peringatan yang tidak perlu, ini adalah peringatan yang sangat relevan. Pengguna Anda, yang sebelumnya tidak tahu bahwa Anda tidak memverifikasi sertifikat, sekarang tahu bahwa ini benar.

Jika peringatan itu tidak berharga untuk modul Anda, itu tidak mungkin berharga untuk modul lain dalam aplikasi (setelah Anda membuang keamanan di satu titik jaringan, tidak ada gunanya membicarakannya di tempat lain). Saya tidak benar-benar melihat masalah dengan menonaktifkannya secara global.

Ketika pengguna secara eksplisit meminta verify=False untuk permintaan tertentu, saya tidak melihat nilai menampilkan peringatan. Ketika saya sebagai pembuat modul mengatur verify=False , saya mengaturnya berdasarkan permintaan pengguna (atau saya jahat, tetapi peringatan itu juga tidak membantu di sana, karena saya dapat membungkam peringatan). Memang, saya ingin menghindari menjadi jahat dan tidak ingin membungkam peringatan secara global, karena itu menghilangkan peringatan yang berguna untuk permintaan tersebut yang dibuat secara tidak aman oleh bagian lain dari aplikasi.

Selain itu, mengaktifkan peringatan untuk permintaan di mana verifikasi secara eksplisit dimatikan oleh pengguna juga menyembunyikan permintaan di mana pengguna menginginkan peringatan, karena peringatan hanya diberikan sekali. Peringatan ini juga tidak terlalu membantu pengguna, karena tidak menyebutkan URL permintaan tertentu.

Saya tidak setuju bahwa membuang keamanan di satu titik jaringan entah bagaimana membuat pemeriksaan keamanan tidak berguna dalam aplikasi, begitu pula vendor browser mana pun. Peramban membiarkan saya melewati pemeriksaan keamanan untuk URL individual tetapi tetap memeriksa sisanya dan saya menyukainya.

Ketika saya memiliki alat yang berbicara ke server internal dengan sertifikat yang ditandatangani sendiri di jaringan internal, tetapi juga berkomunikasi dengan host luar, saya ingin memverifikasi komunikasi luar. Ini akan menjadi situasi di mana saya ingin sebagai pengguna melihat peringatan tentang permintaan tanpa jaminan yang tidak disengaja.

Pertimbangkan saya menghasilkan service_foo dan seseorang menggunakannya di aplikasi:

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)

Saya memiliki 2 opsi untuk service_foo :

1. Saya tetap mengaktifkan peringatan keamanan global
   
   
   
   • Pengguna selalu mendapat peringatan ketika aplikasi berbicara dengan https://10.0.0.1
   
   
   • Pengguna tidak pernah mendapat peringatan meskipun permintaan ke https://example.com/submit tidak aman
   
   
2. Matikan peringatan keamanan global:
   
   
   
   • Pengguna tidak pernah mendapat peringatan meskipun permintaan ke https://example.com/submit tidak aman
   
   

Saya tidak berpikir salah satu opsi itu baik, tetapi opsi 1 lebih buruk, karena memberikan alarm palsu. Tetapi saya tidak nyaman jika pemeriksaan keamanan dimatikan untuk pengguna sebagai efek samping dari penggunaan modul saya.

Jika saya melakukan ini dengan skrip Shell, pengguna akan lebih bahagia dan lebih aman:

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

Bagi saya masuk akal untuk memberikan peringatan jika konfigurasi platform Python rusak. Halaman https://urllib3.readthedocs.org/en/latest/security.html yang ditautkan dalam pesan InsecureRequestWarning memang ditujukan untuk menunjukkan cara memperbaiki masalah di platform. Jika pengguna meminta untuk melewati verifikasi, seharusnya tidak ada peringatan seperti tidak ada peringatan jika pengguna meminta URL http alih-alih URL https .

Ketika pengguna secara eksplisit meminta verifikasi=False untuk permintaan tertentu, saya tidak melihat nilai dari menampilkan peringatan.

Siapa 'pengguna' itu? Sepanjang posting Anda, pertanyaan ini terus muncul di benak saya, karena saya yakin Anda menyatukan dua audiens.

Ketika saya sebagai pembuat modul mengatur verifikasi=False, saya mengaturnya berdasarkan permintaan pengguna (atau saya jahat).

Atau Anda lalai. Anda memiliki pengguna yang mengeluh bahwa mereka tidak dapat melakukan interop dengan sertifikat yang ditandatangani sendiri sehingga Anda mematikan verifikasi sertifikat, meskipun fakta bahwa mematikan verifikasi sertifikat adalah _bukan_ cara untuk mengatasi masalah itu.

yang menghilangkan peringatan yang berguna untuk permintaan tersebut, beberapa bagian lain dari aplikasi tanpa sadar membuat tidak aman

Kalimat ini membuatku bingung. Ini menunjukkan bahwa dapat diterima untuk memperingatkan ketika aplikasi _tidak sadar_ membuat permintaan tidak aman, tetapi aplikasi _mengetahui_ membuat mereka entah bagaimana OK. Saya tidak melihat bagaimana secara sadar membuat permintaan tidak aman dengan cara apa pun harus dianggap 'lebih aman' daripada melakukannya tanpa sadar.

Juga, mengaktifkan peringatan untuk permintaan tersebut di mana verifikasi secara eksplisit dimatikan oleh pengguna

Pengguna yang mana? Bagaimana kita membedakan antara pembuat modul dan 'pengguna', siapa pun mereka?

Peringatan ini juga tidak terlalu membantu pengguna, karena tidak menyebutkan URL permintaan tertentu.

Peringatan tidak boleh menyebutkan URL permintaan, karena akan berisiko menghasilkan spam peringatan. Kami memperingatkan _once_, dengan mengatakan 'aplikasi ini berisiko', bukan 'komunikasi khusus ini berisiko'.

Peramban membiarkan saya melewati pemeriksaan keamanan untuk URL individual tetapi tetap memeriksa sisanya dan saya menyukainya.

Vendor browser _peringatkan_ saat Anda mengakses URL dengan sertifikat yang tidak valid! Mereka mencetak kotak dialog dan menyorot bilah URL dengan warna merah! Itulah _persis_ yang kami lakukan. Kami tidak menghentikan Anda untuk melakukan apa pun, kami hanya mengatakan "hei, ini buruk!" Apa yang Anda minta kami lakukan sama dengan meminta vendor browser untuk mengizinkan pengguna mematikan peringatan merah itu untuk URL tertentu, dan saya jamin mereka akan menolak melakukannya karena implikasi keamanannya mengerikan.

Ketika saya memiliki alat yang berbicara ke server internal dengan sertifikat yang ditandatangani sendiri di jaringan internal, tetapi juga berkomunikasi dengan host luar, saya ingin memverifikasi komunikasi luar.

Tidak, Anda ingin memverifikasi _semua_ komunikasi. Verifikasi sertifikat yang ditandatangani sendiri! Validasi bahwa Anda mendapatkan sertifikat yang Anda harapkan. verify=False harus dianggap sebagai pendekatan palu godam untuk keamanan, yang secara efektif mengatakan "keamanan sekrup, buat saja bekerja". Tidak apa-apa, Anda memiliki hak untuk mengatakan itu, tetapi kami memiliki kewajiban untuk menyebutnya sebagai tidak aman.

Saya tidak berpikir salah satu opsi itu baik, tetapi opsi 1 lebih buruk, karena memberikan alarm palsu.

Opsi 1 tidak memberikan alarm palsu, itu memberikan alarm nyata. Komunikasi ke 10.0.0.1 adalah _tidak aman_, dan kita tidak boleh berpura-pura sebaliknya.

Jika saya melakukan ini dengan skrip shell, pengguna akan lebih bahagia dan lebih aman.

Pengguna mungkin lebih bahagia, tetapi mereka tidak akan lebih aman. Mereka akan sama amannya seperti sebelumnya. Anda tampaknya mendapat kesan bahwa mematikan peringatan ini entah bagaimana secara ajaib membuat verifikasi sertifikat hilang, dan ternyata tidak. Saya akan menyentuh ini lagi di akhir tanggapan ini.

Bagi saya masuk akal untuk memberikan peringatan jika konfigurasi platform Python rusak.

Tidak, kami akan gagal jika konfigurasi platform Python rusak dan Anda tidak meminta permintaan yang belum diverifikasi. Jika platform Anda tidak dapat membuat koneksi TLS yang aman maka kami sama sekali tidak boleh membuatnya, kecuali dalam situasi di mana pengguna kami secara tegas memberi tahu kami untuk tidak peduli (dengan menyetel verify=False ), dalam hal ini kami harus memperingatkan bahwa apa yang Anda akan lakukan berbahaya.

Saya pikir Anda bekerja di bawah kesalahpahaman, jadi saya ingin membuat sesuatu yang sangat jelas: tidak ada cara untuk membuat permintaan HTTPS yang tidak divalidasi dengan permintaan tanpa a) menyetel verify=False (perilaku peringatan kami) atau b) dengan sengaja menyabotase modul ssl . Kami tidak dapat menangkap b) dan tidak memperingatkannya. Ini adalah satu-satunya situasi yang akan jatuh di bawah gagasan yang Anda kemukakan tentang "masalah dengan platform". Saran di halaman bantuan urllib3 tidak berlaku untuk kami karena kami mengambil semua langkah terkait platform yang diperlukan, termasuk menggabungkan sertifikat tepercaya dan memverifikasi sertifikat secara manual.

Ada pandangan berbahaya di komunitas web bahwa Anda hanya boleh memverifikasi sertifikat yang ditandatangani oleh sertifikat akar tepercaya. Pandangan ini benar-benar sesat. Jika Anda menemukan sertifikat yang ditandatangani sendiri, Anda harus memvalidasinya dengan baik. Itu benar-benar bisa dilakukan! Tambahkan sertifikat yang ditandatangani sendiri ke file .pem dan berikan sebagai argumen ke verify !

Jika Anda mengalami masalah dalam menggabungkannya dengan file .pem dibundel, beri tahu saya dan saya akan menyempurnakan mkcert.org untuk memungkinkan Anda menggabungkan sertifikat Anda sendiri dengan akar tepercaya. Tapi tolong, jangan berpura-pura bahwa pengaturan verify=False aman: sebenarnya tidak.

Selain itu, mengaktifkan peringatan untuk permintaan di mana verifikasi secara eksplisit dimatikan oleh pengguna juga menyembunyikan permintaan di mana pengguna menginginkan peringatan, karena peringatan hanya diberikan sekali.

Ini juga agak membingungkan. Dengan menyetel verify=False Anda mungkin secara eksplisit mematikannya hanya untuk permintaan itu, tetapi tidak ada cara untuk menyampaikannya di luar titik di mana kami menyusun permintaan kami. Juga tidak ada alasan untuk menyampaikannya lebih dari itu karena Anda telah menonaktifkan verifikasi sertifikat. Konteks di mana Anda melakukannya bukanlah konsekuensi bagi kami atau siapa pun yang menggunakan aplikasi Anda.

Apa yang Anda minta kami lakukan sama dengan meminta vendor browser untuk mengizinkan pengguna mematikan peringatan merah itu untuk URL tertentu, dan saya jamin mereka akan menolak melakukannya karena implikasi keamanannya mengerikan.

Peramban saya mengizinkan saya untuk menerima sertifikat yang belum diverifikasi secara permanen, yang "sangat tidak aman".

Komunikasi ke 10.0.0.1 tidak aman, dan kita tidak boleh berpura-pura sebaliknya.

Sambungan tidak aman karena Anda tidak dapat memverifikasi sertifikat digital, tetapi memverifikasi sertifikat tidak benar-benar memberi tahu Anda apakah server yang Anda ajak bicara aman. Tetapi ketika saya berbicara dengan server di jaringan tertutup, saya benar-benar dapat memastikan keamanan server.

Saya pikir Anda bekerja di bawah kesalahpahaman, jadi saya ingin membuat sesuatu yang sangat jelas: tidak ada cara untuk membuat permintaan HTTPS yang tidak divalidasi dengan permintaan tanpa a) pengaturan verifikasi=False (perilaku peringatan kami) atau b) sengaja menyabotase ssl

Saya mencoba bertanya-tanya bagaimana saya bisa menjadi warga negara yang baik dalam modul saya dengan menghormati keinginan pengguna untuk mengabaikan pemeriksaan sertifikat dan peringatan untuk URL yang mereka berikan kepada saya. Dan nilai apa yang ditambahkan oleh model peringatan. Bagaimana kasus di mana permintaan dengan verify=False harus menampilkan peringatan kepada pengguna?

Saya tidak melihat bagaimana mekanisme peringatan dapat menangkap kode yang lalai, karena tidak dapat membedakan apakah permintaan dibuat karena pengkodean yang ceroboh atau karena pengguna meminta demikian. Saya tidak berpikir modul seperti requests harus mendikte kebijakan keamanan juga. Saya mengerti bahwa peringatan biasanya ditujukan untuk pengembang sehingga mereka dapat memperbaiki kode yang salah, tetapi peringatan ini tidak seperti itu. Jika peringatan itu hanya untuk pendidikan umum pengguna, seharusnya ada cara mudah bagi pengguna untuk menyembunyikannya.

Mendapatkan peringatan tidak hanya kosmetik juga, karena mengacaukan output dari sebuah program.

Saya hanya melihat nilai negatif dari peringatan itu, jadi saya mematikannya di modul saya bahkan jika saya benci menyembunyikan perubahan kebijakan global di sana.

Ada pandangan berbahaya di komunitas web bahwa Anda hanya boleh memverifikasi sertifikat yang ditandatangani oleh sertifikat akar tepercaya. Pandangan ini benar-benar sesat.

Tidak tahu ada pemandangan seperti itu. Sertifikat yang ditandatangani oleh sertifikat root tidak benar-benar membuktikan apa pun tentang keamanan situs. Itu murah untuk mendapatkan sertifikat anonim jika Anda ingin melakukan hal-hal buruk.

Jika Anda menemukan sertifikat yang ditandatangani sendiri, Anda harus memvalidasinya dengan baik. Itu benar-benar bisa dilakukan! Tambahkan sertifikat yang ditandatangani sendiri ke file .pem dan berikan sebagai argumen untuk memverifikasi!

Pengguna akan membutuhkan saluran aman untuk mendapatkan sertifikat, seperti jaringan tepercaya internal. Tetapi jika server itu sendiri berada di jaringan internal yang sama, tidak banyak yang didapat. Tetapi bagaimanapun juga ini adalah sesuatu yang diputuskan oleh pengguna, saya tidak dapat memaksakan kebijakan dalam modul saya.

Saya setuju dengan @kankri , untuk sebagian besar. Itu adalah niat desain aslinya.

Saya mengusulkan sesuatu — yang kami nonaktifkan secara default tetapi memiliki fungsi kami sendiri untuk mengaktifkannya kembali, atau mendokumentasikan cara mengaktifkannya. Saya tidak ingin pengguna keluar untuk menggunakan kode sebagaimana dimaksud. verify=False adalah fitur, meskipun bukan yang terbaik. Itu bukan urusan kita.

Saya setuju bahwa verify=False adalah sebuah fitur, tetapi saya tidak setuju bahwa itu adalah fitur pada level yang sama dengan params= atau cert= . Ini adalah fitur yang default ke nilai aman dan mungkin disetel ke nilai tidak aman. Ini adalah pilihan raksasa yang menggoda bagi orang-orang untuk membuang keamanan ke luar jendela demi kemanfaatan, dan saya pikir dorongan itu harus dilawan (tetapi tidak dilarang). Saya akan selalu condong ke aliran pemikiran 'Anda harus secara eksplisit tidak aman', dan saya tidak peduli apakah itu berarti menjentikkan dua sakelar dan bukan satu.

Bagaimanapun, ini adalah panggilanmu bukan milikku. =)

Hanya ingin mengatakan saya setuju dengan @kankri dan komentar @kennethreitz itu

verifikasi=False adalah fitur, meskipun bukan praktik terbaik. Itu bukan urusan kita.

merangkumnya dengan baik.

Bagi mereka yang juga ingin menonaktifkan peringatan, ini adalah cara melakukannya. Anda perlu menggunakan modul peringatan , yang merupakan bagian dari perpustakaan standar:

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)

Ini mengonfigurasi filter peringatan yang akan mengabaikan peringatan kategori apa pun InsecureRequestWarning . Outputnya terlihat seperti:

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

(Situs pengujian kebetulan mengembalikan halaman 403 Terlarang, tapi itu tidak penting di sini.)

Perhatikan bahwa Anda perlu menggunakan kelas dari dibundel urllib3 paket, dan tidak kelas dari tingkat atas urllib3 paket, jika Anda kebetulan memiliki satu diinstal.

Anda dapat (dan mungkin harus) membuat fungsi kecil yang menggunakan pengelola konteks di wilayah kode sekecil mungkin:

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

Atau cukup lakukan ini:

requests.packages.urllib3.disable_warnings()

@Lukasa

Atau cukup lakukan ini:

requests.packages.urllib3.disable_warnings()

Kecuali bahwa saya tidak menemukan penyebutan fungsi ini dalam manual permintaan.

Meskipun jauh dari semua orang yang mengetahuinya, saya berpendapat bahwa modul warnings _is_ alat standar yang harus dilihat oleh programmer Python ketika dia ingin menonaktifkan peringatan. Ini adalah bagian dari perpustakaan standar dan didokumentasikan dengan baik.

Saya menyarankan untuk memasukkan referensi ke warnings ke dalam dokumentasi requests — atau ke fungsi disable_warnings jika Anda mau, selama ada enable_warnings function ( sepertinya tidak ada function ).

Sekali lagi: Saya tidak ingin menonaktifkan peringatan secara umum. Saya hanya ingin peringatan khusus ini hilang ketika saya _explicitly_ mengatur verifikasi=False dalam kode saya. Mungkin ada peringatan lain yang berguna, tidak seperti peringatan khusus yang tidak berguna ini. Apa yang begitu sulit untuk dipahami tentang ini?!

@zaitcev Dengan risiko mengulang sendiri:

requests.packages.urllib3.disable_warnings()

Dan bahkan jika itu terlalu luas untuk Anda:

from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

Akhirnya, sebuah catatan, @zaitcev : Anda akan menemukan bahwa mengambil nada jengkel yang baru saja Anda lakukan tidak menguntungkan Anda sama sekali. Ingatlah bahwa kita semua adalah sukarelawan, dan bahwa kita memiliki waktu terbatas yang dapat kita berikan untuk membangun sesuatu bagi Anda. Silakan coba perlakukan kami sebagaimana Anda ingin diperlakukan.

@zaitcev Sepertinya ini tidak akan berubah dalam modul permintaan itu sendiri, tetapi saya harap Anda dapat menggunakan kode yang saya masukkan di komentar saya yang lain . Itu akan memungkinkan Anda untuk menonaktifkan peringatan yang dipancarkan oleh urllib3 secara selektif.

Anda juga dapat menekannya dengan:

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

Dalam kasus saya, saya tidak menggunakan permintaan secara langsung, jadi menekan seperti ini membuat saya sedikit khawatir akan rusak nanti.

@zaitcev Menarik semua saran sebelumnya bersama-sama, Anda dapat melakukan sesuatu seperti ini:

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 Itu akan membuat peringatan dinonaktifkan untuk semua permintaan berikutnya.

Menyatukan contoh lain, saya memperluas default Session (sebagai requests.get dan pintasan lain membuat 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)

Menonaktifkan semua peringatan dari requests kemungkinan merupakan ide yang buruk, mungkin sedikit lebih baik:

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

Untuk meringkas bagaimana saya menangani ini:

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

Ini memungkinkan saya untuk memeriksa apakah permintaan tidak aman, menyembunyikan peringatan urllib dan meningkatkan peringatan pemformatan saya sendiri untuk pengguna. Itu memang mengharuskan permintaan dibuat dua kali. Diedit untuk membuat klausa kecuali kurang luas.

except Exception: SANGAT luas. Anda benar-benar tidak menginginkan itu.

Hal di atas menunjukkan beberapa cara untuk mengatasi kekhawatiran di kedua sisi diskusi ini.

bukankah itu melempar beberapa subkelas Pengecualian yang bisa Anda tangkap?

Atau gunakan logging.captureWarnings()

Alternatifnya adalah mengetahui bahwa urllib3 terlibat dan hardcode namespace-nya, lihat komentar oleh tuukkamustonen. Ini adalah keberatan utama saya: mereka bisa membuatnya bekerja dengan benar, saya bahkan memberikan tambalan dalam permintaan tarik. Tetapi mereka menyangkal bahwa masalahnya ada dan memberi tahu semua pengguna untuk menemukan solusi yang buruk seperti "kecuali Pengecualian" atau "dari pengecualian impor request.packages.urllib3". Pada titik ini seseorang harus mengakui bahwa mereka salah selama ini dan kami terjebak.

Ini adalah keberatan utama saya: mereka bisa membuatnya bekerja dengan benar, saya bahkan memberikan tambalan dalam permintaan tarik. Tetapi mereka menyangkal bahwa masalahnya ada dan memberi tahu semua pengguna untuk menemukan solusi yang buruk seperti "kecuali Pengecualian" atau "dari pengecualian impor request.packages.urllib3". Pada titik ini seseorang harus mengakui bahwa mereka salah selama ini dan kami terjebak.

@zaitcev Sekali lagi, izinkan saya mengingatkan Anda bahwa ini adalah komunitas sukarelawan yang melakukan yang terbaik yang mereka bisa. Kami telah membiarkan masalah ini bebas untuk didiskusikan, kami tidak berusaha untuk menguncinya atau mencegah diskusi lebih lanjut. Kami _mendengarkanmu_. Apa yang tidak kami lakukan adalah segera menyetujui penilaian Anda terhadap situasi tersebut. Harap pertimbangkan kemungkinan bahwa kami peduli dengan lebih banyak kasus penggunaan daripada hanya milik Anda, dan bahwa kami perlu menyeimbangkan kebutuhan semuanya.

Mengenai permintaan tarik Anda, permintaan itu ditolak karena _alasan yang sangat spesifik_ yang terus-menerus Anda abaikan! Izinkan saya mengutip diri saya mengutip Ian :

Pernyataan penutupnya adalah: "Mengingat bahwa ini sebagian besar di urllib3 dan akan bergantung pada penerimaan di sana, saya menutup ini sampai kemajuan telah dibuat di sana. " (Penekanan milik saya.)

Sampai hari ini saya masih tidak melihat permintaan tarik atau masalah terkait untuk masalah ini di urllib3. Tidak seorang pun dari proyek ini yang menghalangi Anda atau mencegah pekerjaan ini terjadi, kami tidak memilih untuk melakukannya sendiri karena _saat ini kami tidak setuju dengan Anda_.

Namun, dengan risiko jatuh ke lubang kelinci ini lagi, izinkan saya mengulangi:

Ini adalah keberatan utama saya: mereka bisa membuatnya bekerja dengan benar.

Saya tidak percaya tambalan Anda membuat ini berfungsi "benar" . Seperti yang telah saya katakan berkali-kali di utas ini, saya menganggap perilaku saat ini diinginkan. Melakukan permintaan TLS yang tidak aman adalah ide yang buruk, dan pengguna harus diperingatkan untuk tidak melakukannya.

Posisi saya adalah bahwa pengguna _layak mengetahui_ ketika mereka membuat permintaan TLS yang tidak cukup diamankan, terutama di sistem apa pun yang menangani kata sandi mereka.

Ada kesepakatan di utas ini bahwa kita harus mempertimbangkan untuk memiliki kait tingkat permintaan untuk menonaktifkan peringatan ini. Di sisi lain, saat ini tidak seorang pun kecuali Anda yang percaya bahwa beberapa perbedaan yang sebelumnya tidak ada antara verify=False dan verify=None harus ditambahkan untuk secara implisit membungkam peringatan ini. Anda akan merasa jauh lebih mudah untuk melakukan yang pertama daripada yang terakhir.

+1 untuk tidak membedakan antara verifikasi=Salah dan verifikasi=Tidak ada. Saya akan mendukung:

• menambahkan parameter baru (misalnya, noInsecureWarnings), atau
• memiliki permintaan mencegat peringatan urllib3 dan mengeluarkannya sendiri, jadi (a) saya dapat menekan sesuatu yang kurang menakutkan daripada 'requests.packages.urllib3.exceptions.InsecureRequestWarning' (yang sudah merupakan permintaan khusus, tetapi akan rusak jika permintaan bermigrasi ke pustaka dasar yang berbeda), dan (b) peringatan dapat mengarah ke URL khusus permintaan (URL saat ini tidak relevan karena peringatan telah diarsir!)

Dan terima kasih kepada semua sukarelawan untuk mendukung permintaan, apakah ini diperbaiki atau tidak: ini perpustakaan yang bagus :)

Ini adalah perpustakaan yang luar biasa, terima kasih atas semua kerja keras Anda.

Saya menemukan masalah ini setelah memutakhirkan paket python saya baru-baru ini dan memperhatikan banyak cetakan InsecurePlatformWarning baru. Jadi saya menyumbangkan kasus penggunaan saya, yang menurut saya menarik.

Saya menggunakan permintaan untuk mengelola server jenkins di 4 lingkungan berbeda. Tiga dari lingkungan (pengembangan, pementasan, produksi) semuanya memiliki sertifikat yang valid. Lingkungan ke-4 adalah kotak virtual gelandangan, yang dapat digunakan pengembang untuk menguji perubahan pada mesin lokal mereka. Ini tidak memiliki sertifikat yang valid, tetapi sebagai kebijakan, semua konfigurasi server menolak permintaan yang tidak terenkripsi.

Pengaturan koneksi jenkins (nama server, token, dll) untuk lingkungan menyertakan tanda khusus untuk mematikan verifikasi ssl, yang hanya disetel ke True untuk lingkungan gelandangan.

Dalam pengaturan saya, menonaktifkan peringatan secara global akan menjadi ide yang buruk karena proyeknya agak besar dan banyak permintaan dapat dibuat, dengan atau tanpa perpustakaan permintaan. Menonaktifkan peringatan dalam ruang lingkup akan baik-baik saja, kecuali bagian dari proyek mencakup aplikasi labu dan kasus multi-utas lainnya yang mungkin.

Menurut pendapat saya, sepertinya penggunaan verifikasi=False harus didukung dan berfungsi seperti yang diharapkan, tanpa peringatan. Terserah pengembang aplikasi untuk memutuskan kapan dan apakah ini harus diizinkan. Misalnya, jika saya menulis browser untuk penggunaan umum, maka saya tidak akan pernah menyetel ini ke True tanpa menampilkan dialog konfirmasi besar dengan banyak teks merah. Tetapi jika saya memiliki server dan klien dan memiliki alasan sendiri untuk tidak mengeluarkan sertifikat, saya harus dapat memiliki log yang bersih dan tidak menyembunyikan potensi masalah lainnya.

Terserah pengembang aplikasi untuk memutuskan kapan dan apakah ini harus diizinkan.

Pertentangan ini adalah di mana saya berbeda dengan Anda. Saya percaya terserah pengembang untuk memutuskan kapan mereka harus menggunakannya. Tapi saya percaya terserah _user_ untuk memutuskan apakah pilihan itu dapat diterima. Adalah _penting_ bagi pengguna untuk memahami ketika mereka ditempatkan dalam risiko oleh pilihan pengembang, dan bahwa mereka dapat mengevaluasi risiko tersebut.

Tetapi jika saya memiliki server dan klien dan memiliki alasan sendiri untuk tidak mengeluarkan sertifikat, saya harus dapat memiliki log yang bersih dan tidak menyembunyikan potensi masalah lainnya.

Dan Anda dapat melakukannya, dengan menggunakan pengelola konteks logging untuk menangkap peringatan tersebut. Kami juga mempertimbangkan agar permintaan membuat peringatan ini lebih spesifik untuk permintaan sehingga lebih mudah ditangkap, tetapi itu belum terjadi.

Saya memiliki situasi yang mirip dengan @jamie-sparked.

Saya mengerti maksud Lukasa dalam menegakkan keamanan, tetapi saya pikir Anda harus membiarkan pengguna ANDA memutuskan apa yang terbaik untuk mereka.
Permintaan adalah perpustakaan, bukan aplikasi pengguna akhir. IMO Anda harus mempertimbangkan pengembang sebagai pengguna Anda.
Pengembang aplikasi harus bertanggung jawab atas kesalahan keamanan, jika mereka memutuskan untuk mematikan verifikasi sertifikat (yaitu verifikasi=False)

Sebagai pengembang, saya menghargai fleksibilitas atas perpustakaan yang mencoba mendikte apa yang harus saya lakukan.

BTW seperti yang dikatakan orang lain, saya menemukan permintaan _sangat baik_ dan saya menghargai semua upaya Anda. Terima kasih.

@thalesac Kami _do_ membiarkan pengembang memutuskan. Seperti yang dibahas _banyak_ kali di utas ini, sangat mungkin untuk mematikan peringatan ini. Namun, kami tidak memiliki satu sakelar yang mematikan semua peringatan: Anda harus melakukannya secara manual. Ini adalah upaya untuk membuat pengguna kami _secara sadar_ menghapus setiap penjaga keamanan.

Anggap saja sebagai pertahanan yang mendalam. Untuk menggunakan analogi footgun, kami memberikan Anda pistol dengan pengaman dan tidak ada peluru di dalamnya, dan sebuah magasin. Jika kita memiliki verify=False menonaktifkan semua peringatan, itu akan sama dengan memiliki senjata yang, ketika magasin dimasukkan, secara otomatis menonaktifkan keamanan dan menyimpan peluru. Nyaman? Tentu. Berbahaya? Anda bertaruh.

Saya khawatir, saya tidak setuju dengan model analogi Anda.
Saya akan mengatakan verifikasi=False IS mekanisme keselamatan/keamanan Anda. Jika Anda secara eksplisit (atau secara manual) menonaktifkannya, Anda tidak ingin pistol memperingatkan Anda sepanjang waktu saat Anda menembak orang jahat. Jelas perilaku default harus menegakkan pemikiran keamanan.
Bagaimanapun, saya mengerti ini hanya pandangan saya dan Anda harus melakukan apa yang menurut Anda terbaik untuk proyek Anda. Mungkin itu sebabnya perpustakaan ini bagus. :)
Terima kasih

Saya sangat setuju dengan Lukasa, keamanan yang pertama dan jika sebagai pengembang saya menggunakan verifikasi=False di salah satu bagian dari kode saya maka saya harus menekan peringatan, jika saya tidak ingin diperingatkan.

Pokoknya perpustakaan yang luar biasa, penggemar berat kerja tim Anda, pertahankan, +10000 untuk kesabaran dalam menanggapi kami.

Cara saya melihatnya, jika aplikasi menggunakan url yang ditetapkan oleh pengguna maka pengguna harus diberikan opsi untuk menonaktifkan verifikasi tetapi dalam setiap situasi yang dapat saya pikirkan mereka harus mendapatkan peringatan. Jika sebagai pengembang dan Anda tahu untuk alasan apa pun Anda terhubung ke url yang tidak diharapkan memiliki sertifikat yang valid (layanan internal yang tidak akan Anda bayar untuk sertifikat, uji, dll) maka Anda harus memiliki opsi untuk menonaktifkan peringatan bersama dengan menonaktifkan verifikasi.

Pada saat yang sama saya tidak berpikir itu akan menjadi umum untuk memiliki situasi di mana Anda ingin menonaktifkan peringatan secara global sekaligus karena itu membuatnya terlalu mudah untuk membuka masalah keamanan yang diabaikan secara diam-diam.

requests.packages.urllib3.disable_warnings() ya berhasil

Hai, yang di sana

Apakah requests.packages.urllib3.disable_warnings() tidak berfungsi lagi? itu digunakan untuk membungkam peringatan untuk saya. Di sinilah saya memanggil fungsi peringatan nonaktifkan, dan berikut adalah contoh penelusuran balik di mana fungsi peringatan dipanggil:

 [+] Diterima pengalihan ke 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()
 -> kembalikan fungsi()
 /usr/local/lib/python2.7/dist-packages/cement/core/controller.py(472)_dispatch()
 -> kembalikan fungsi()
 /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)) == Benar:
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py(910)cms_identify()
 -> header)
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py(827)enumerate_file_hash()
 -> r = self.session.get(url + file_url, timeout=timeout, header=header)
 /usr/lib/python2.7/dist-packages/requests/sessions.py(480)get()
 -> kembalikan self.request('GET', url, **kwargs)
 /usr/lib/python2.7/dist-packages/requests/sessions.py(468)request()
 -> resp = self.send(persiapan, **send_kwargs)
 /usr/lib/python2.7/dist-packages/requests/sessions.py(576)send()
 -> r = adapter.send(permintaan, **kwargs)
 /usr/lib/python2.7/dist-packages/requests/adapters.py(376)send()
 -> batas waktu = batas waktu
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(559)urlopen()
 -> body=body, header=tajuk)
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(345)_make_request()
 -> self._validate_conn(sambungan)
 > /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(791)_validate_conn()
 -> warnings.warn((

Berikut ini adalah output dari pip freeze , saya menggunakan pengujian debian:

 argparse == 1.2.1
 sup indah4==4.4.1
 semen == 2.6.2
 chardet == 2.3.0
 colorama==0.3.3
 cakupan == 4.0.3
 kriptografi == 1.2.1
 distlib==0.2.1
 -e [email protected]:droope/droopescan.git@6524a9235e89a6fdb3ef304ee8dc4cb73eca0386#egg=droopescan-pengembangan
 enum34==1.1.2
 fungsi == 0.4
 berjangka = 3.0.4
 html5lib==0,999
 httplib2==0.9.1
 idna==2.0
 alamat ipad == 1.0.16
 lxml==3.5.0
 lincah == 3.5.2
 tiruan = 1.3.0
 ndg-httpsklien==0.4.0
 hidung == 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
 laporan bug == 6.6.6
 permintaan == 2.9.1
 tanggapan==0.3.0
 mencoba lagi == 1.3.3
 enam == 1.10.0
 urllib3==1.13.1
 roda == 0.26.0
 wsgiref==0.1.2

Terima kasih,
Pedro

disable_warnings tidak mencegah fungsi peringatan dipanggil, itu hanya menekan output. Anda mungkin mengalami masalah jika beberapa kode lain mengaktifkan semua peringatan.

Hai @Lukas ,

Saya menempatkan breakpoint setelah if. Pada akhirnya saya berhenti menggunakan pengujian debian karena saya menemukan terlalu banyak masalah, dan ini mungkin salah satunya. Saya hanya akan mengabaikan komentar saya, saya tidak yakin apa yang terjadi tetapi kemungkinan itu bukan sesuatu yang akan mempengaruhi banyak orang.

Terima kasih!
Pedro

Ya, jadi jika Anda menggunakan paket dari debian, mungkin logika unvendoring mereka merusak sesuatu di sini.

Ingin membuat permintaan tidak aman dengan menentukan verify=False dan tidak melihat peringatan untuk permintaan itu, tanpa mengganggu peringatan untuk permintaan lain yang dibuat di tempat lain tampaknya sangat masuk akal.

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