Requests: تحقق = خطأ وطلبات .packages.urllib3.disable_warnings ()

أعتقد أنه يمكنك تعطيل هذه على المستوى العالمي باستخدام الوحدة النمطية warnings . علاوة على ذلك ، للعمل مع التسجيل (إذا كنت أتذكر بشكل صحيح) ، تحتاج إلى الوصول إلى urllib3 (ونحن نوثق ذلك) ، لذلك أنا لا أعارض توثيق ذلك للمستخدمين الذين لن يستخدموا التحقق من الشهادة لـ HTTPS روابط.

ما زلت أؤيد بشدة ترك هذه التحذيرات في مكانها. نعم ، إنهم مزعجون ، لكنهم موجودون أيضًا لسبب ما. إذا كان هناك أي شيء ، فأنا أميل إلى إيقاف تشغيله واستبداله بواحد خاص بنا! = ص

في هذه المرحلة ، من الواضح إلى حد ما أن Lukasa وأنا -1 في هذه الميزة. @ kennethreitz @ shazow أي آراء؟

إلى حد ما ، أوافق على أن التحذيرات مهمة ، لكنني أعتقد أن هناك عدة عوامل قد تحتاج إلى أخذها في الاعتبار.

من وجهة نظر المطور ، أعلم أنني أعلم بهذا ، يمكنني فقط إيقاف تشغيله إذا شعرت بالميل. أنا أحدث في الحزم ، لذلك عندما أقرأ المستندات ، في التحذير ، لم ينجح هذا الحل في الواقع. تعجبني الفكرة التي قدمها Lukasa حول صنع شيء خاص بـ requests .

من منظور المستخدم ، قمت بتثبيت pyvmomi مع pip اليوم ، والذي يستخدم requests في عناصره الداخلية. إنه خطأ غير شفاف حقًا يتم إرساله مرة أخرى إلى المستخدم في حالة يكون فيها requests مكتبة دعم صامتة.

نعم ، requests.packages.urllib3.disable_warnings() هو اختصار لإيقاف تشغيله باستخدام تصفية وحدة التحذيرات.

أوصي بشدة بوجود نوع من التحذير لهذا الغرض. +0.5 عند وجود urllib3 واحد للتكاثر ، +1 إذا كنت تريد بذل الجهد وإضافة طلب خاص بالطلبات. -1 على عدم وجود تحذير.

إذا كنت ترغب في ذلك ، يمكننا أن نجعل رسالة تحذير urllib3 قابلة للتكوين ويمكنك تجاوزها حتى تتمكن من استخدام نفس المنطق بخلاف ذلك.

مرة أخرى ، لا أعتبر هذه الرسالة معادية للمستخدم ، فأنا أعتبرها قيّمة للغاية. أنت تعرف الآن أن pyvmomi قد أوقف التحقق من شهادة TLS ، وهي معلومات مهمة إلى حد ما!

بعد قولي هذا ، لا أعترض على وجود طريقة طلبات أكثر لإسكاتها.

نعم ، أعتقد حقًا أن هذا خطأ في pyvmomi . إذا كانوا لا يريدون الشعور بالحرج مثل هذا ، فيجب عليهم تعطيل التحذيرات في أداتهم. ليس من واجبنا أن نحذر المستخدمين من أن الاتصالات التي تجريها بعض الأدوات قد تعرضهم لهجمات MITM لأن الأداة لا تقوم بالتحقق من الشهادة.

شكرا على المناقشة يا رفاق! أنا أقدر حقًا تعليق كل شخص ، ومساعدتي في رؤية القيمة في الطريقة التي تتم بها الأمور ، ولماذا. كنت أواجه صعوبة في رؤية الحالات الأكثر عمومية! :)

ستعمل على التصحيح اليوم ، كما يسمح الوقت ، للحصول على طريقة "الطلبات ذ" لإسكات الصوت. التعليقات ستكون موضع ترحيب!

invisiblethreat لا تتردد في الانتقال إلى IRC إذا كانت لديك أسئلة

فقط أتساءل عما إذا كنت قد نظرت في الحالة التي يتم فيها استخدام الطلبات في الويب هوك. يجب أن أقوم بإلغاء التحذير حتى لا يلوث إخراج JSON للنص البرمجي (أو أفقد شيئًا ما؟)

macterra لست متأكدًا من فهمي. هل تبحث عن استراتيجيات بديلة لتعطيل التحذير أو ...؟

كما أنه من غير الواضح تمامًا بالنسبة لي سبب قيام خطاف الويب بتعطيل التحقق من الشهادة. أريد ترك ذلك.

علاوة على ذلك ، إذا كنت تقوم بتوصيل stdout من بعض البرامج النصية للحصول على النتائج ، فستظهر التحذيرات من stderr حتى لا تلوث إخراج JSON الخاص بك.

صحيح ، إذا كان التحذير على stderr فلا مشكلة. لم أستطع التمييز من النظر إلى الإخراج في وحدة التحكم ، خطأي.

أعتقد أنه يجب علينا تخصيص هذا للإشارة إلى وثائق الطلبات بدلاً من وثائق urllib3.

لست متأكدًا من أنني أفهم الغرض من ميزة التحذير هذه وكيفية التحكم في التحذير.

لدي وحدة تستخدم requests وعليها تقديم طلبات باستخدام الوسيطة verify=False . يؤدي هذا إلى رؤية مستخدمي الوحدة النمطية الخاصة بي للتحذير غير الضروري. تزيد التحذيرات غير الضرورية من صعوبة رؤية التحذيرات المهمة ،

سيكون من المنطقي أن تقوم الوحدة النمطية الخاصة بي بتعطيل التحذير ، ولكن بعد ذلك _ سأقوم بتعطيل التحذير أيضًا في أي وحدة نمطية أخرى_ باستخدام requests في التطبيق!

لن تكون الأمور أفضل إذا كنت بحاجة إلى إرشاد مستخدم الوحدة النمطية الخاصة بي لتعطيل التحذير: حقيقة أنني أستخدم requests عادةً ما تكون مجرد تفاصيل تنفيذ غير مرئية يجب ألا يحتاج المستخدم إلى معرفتها. ولا يزال لدى المستخدم خيار إسكات كل شيء أو الإشارة إليه.

لا أعتقد أن التحذيرات العالمية ستكون مفيدة.

كان بإمكاني استخدام فئة فرعية urllib3.HTTPSConnectionPool وتجاوز _validate_conn() وجعل requests استخدم ذلك في الوحدة النمطية الخاصة بي لتجنب إخفاء التحذيرات من الوحدات النمطية الأخرى ، ولكن يبدو أن هذا يتطلب الكثير من العمل لشيء بسيط .

لست متأكدًا من فهمي لما تهدف ميزة التحذير هذه إلى تحقيقه

يتسبب في رؤية مستخدمي الوحدة النمطية الخاصة بي للتحذير غير الضروري.

عندما تقوم بتعيين verify=False فإنك لم تعد تؤمن اتصالات الشبكة الخاصة بك. هذا ، IMHO ، _ ليس تحذيرًا غير ضروري ، إنه تحذير وثيق الصلة بالموضوع. المستخدمون لديك ، الذين لم يكن لديهم في السابق أي فكرة أنك لم تكن تتحقق من الشهادات ، يعرفون الآن أن هذا صحيح.

إذا لم يكن التحذير ذا قيمة للوحدة الخاصة بك ، فمن غير المحتمل أن يكون ذا قيمة لأي وحدة نمطية أخرى في التطبيق (بمجرد التخلص من الأمان في نقطة شبكة واحدة ، لا داعي للقلق بشأنه في أي مكان آخر). لا أرى مشكلة في تعطيله على مستوى العالم.

عندما يطلب المستخدم صراحةً verify=False لطلب معين ، لا أرى قيمة إظهار تحذير. عندما أقوم كمؤلف للوحدة بتعيين verify=False ، قمت بتعيينه بناءً على طلب المستخدم (أو أكون ضارًا ، لكن التحذير لا يساعد هناك أيضًا ، لأنني أستطيع إسكات التحذيرات). في الواقع ، أريد أن أتجنب أن أكون خبيثًا ولا أريد إسكات التحذيرات عالميًا ، لأن ذلك يزيل التحذير المفيد لتلك الطلبات ، حيث أن جزءًا آخر من التطبيق يصدر عن غير قصد بطريقة غير آمنة.

أيضًا ، يؤدي تشغيل التحذير لتلك الطلبات التي يتم فيها إيقاف تشغيل التحقق صراحة من قبل المستخدم أيضًا إلى إخفاء الطلبات التي يرغب المستخدم في تحذيرها ، حيث يتم إعطاء التحذير مرة واحدة فقط. التحذير أيضًا ليس مفيدًا حقًا للمستخدم ، لأنه لا يذكر عنوان URL للطلب المحدد.

لا أوافق على أن التخلص من الأمان في نقطة شبكة واحدة يجعل أي فحوصات أمنية عديمة الفائدة في التطبيق بطريقة ما ، ولا يفعل أي بائع متصفح. تسمح لي المتصفحات بتجاوز فحوصات الأمان لعناوين URL الفردية ولكن استمر في التحقق من الباقي وأحب ذلك.

عندما يكون لديّ أداة تتحدث إلى خادم داخلي بشهادة موقعة ذاتيًا في شبكة داخلية ، ولكنها تتواصل أيضًا مع مضيفين خارجيين ، فأنا أرغب في التحقق من الاتصال الخارجي. سيكون هذا هو الموقف الذي أرغب كمستخدم في رؤية تحذيرات حول الطلبات غير الآمنة بطريق الخطأ.

ضع في اعتبارك أنني أجني service_foo ويستخدمه شخص ما في أحد التطبيقات:

import service_foo
import requests

session = service_foo.Session('https://10.0.0.1', verify=False)
data = session.get_data()
requests.put('https://example.com/submit', data=data)

لدي خياران مقابل service_foo :

1. أحافظ على تحذير الأمن العالمي قيد التشغيل
   
   
   
   • يتلقى المستخدم دائمًا تحذيرًا عندما يتحدث التطبيق إلى https://10.0.0.1
   
   
   • لا يتلقى المستخدم تحذيرًا أبدًا حتى إذا كان طلب https://example.com/submit غير آمن
   
   
2. قم بإيقاف تشغيل تحذير الأمان العالمي:
   
   
   
   • لا يتلقى المستخدم تحذيرًا أبدًا حتى إذا كان طلب https://example.com/submit غير آمن
   
   

لا أعتقد أن أيًا من الخيارين جيد ، لكن الخيار الأول أسوأ ، لأنه يعطي إنذارات خاطئة. لكنني لست مرتاحًا لإيقاف عمليات فحص الأمان للمستخدم كأثر جانبي لاستخدام الوحدة الخاصة بي.

إذا كنت سأفعل ذلك باستخدام برنامج نصي شيل ، فسيكون المستخدم أكثر سعادة وأمانًا:

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

بالنسبة لي ، من المنطقي فقط إعطاء تحذير في حالة تعطل تكوين منصة Python. الصفحة https://urllib3.readthedocs.org/en/latest/security.html المرتبطة برسالة InsecureRequestWarning موجهة بالفعل لإظهار كيفية إصلاح المشاكل في النظام الأساسي. إذا طلب المستخدم تخطي التحقق ، فلا يجب أن يكون هناك تحذير مثل عدم وجود تحذير إذا طلب المستخدم عنوان URL http بدلاً من https واحد.

عندما يطلب المستخدم صراحةً التحقق = خطأ لطلب معين ، لا أرى قيمة إظهار تحذير.

من هو "المستخدم"؟ خلال رسالتك ، ظل هذا السؤال يتبادر إلى ذهني ، لأنني أعتقد أنك تخلط بين جمهورين.

عندما أعمل كمؤلف للوحدة النمطية على التحقق = خطأ ، أقوم بتعيينه بناءً على طلب المستخدم (أو أكون ضارًا).

أو أنك مهمل. لقد كان لديك مستخدمون يشكون من عدم تمكنهم من التداخل مع الشهادات الموقعة ذاتيًا الخاصة بهم ، ولذا قمت بإيقاف تشغيل التحقق من الشهادة ، على الرغم من حقيقة أن إيقاف تشغيل التحقق من الشهادة _ليس _ الطريقة للتعامل مع هذه المشكلة.

هذا يزيل التحذير المفيد لتلك الطلبات ، وبعض الأجزاء الأخرى من التطبيق تجعلها غير آمنة دون قصد

هذه الجملة تحيرني. يقترح أنه من المقبول التحذير عندما يقدم أحد التطبيقات - عن علم - طلبات غير آمنة ، ولكن تطبيق ما - عن علم - جعلها على ما يرام إلى حد ما. لا أرى كيف يجب اعتبار تقديم الطلبات غير الآمنة عن قصد بأي شكل من الأشكال "أكثر أمانًا" من القيام بذلك عن غير قصد.

أيضًا ، وجود تحذير لتلك الطلبات حيث تم إيقاف التحقق صراحة من قبل المستخدم

أي مستخدم؟ كيف يمكننا التمييز بين مؤلف الوحدة و "المستخدم" ، أياً كان؟

التحذير أيضًا ليس مفيدًا حقًا للمستخدم ، لأنه لا يذكر عنوان URL للطلب المحدد.

يجب ألا يذكر التحذير عنوان URL للطلب ، لأن ذلك قد يؤدي إلى إنشاء رسائل تحذير غير مرغوب فيها. نحذر _ مرة _ بقول "هذا التطبيق في خطر" وليس "هذا الاتصال بعينه في خطر".

تسمح لي المتصفحات بتجاوز فحوصات الأمان لعناوين URL الفردية ولكن استمر في التحقق من الباقي وأحب ذلك.

بائعي المستعرض _حذر_ عند الوصول إلى عنوان URL بشهادة غير صالحة! يطبعون مربعات الحوار ويبرزون شريط URL باللون الأحمر! هذا _ بالضبط_ ما نفعله. نحن لا نمنعك من فعل أي شيء ، نحن نقول فقط "مرحبًا ، هذا سيء!" ما تطلب منا القيام به هو نفس مطالبة بائعي المستعرضات بالسماح للمستخدمين بإيقاف هذا التحذير الأحمر لعناوين URL معينة ، وأنا أضمن أنهم سيرفضون القيام بذلك لأن الآثار الأمنية وحشية.

عندما يكون لديّ أداة تتحدث إلى خادم داخلي بشهادة موقعة ذاتيًا في شبكة داخلية ، ولكنها تتواصل أيضًا مع مضيفين خارجيين ، فأنا أرغب في التحقق من الاتصال الخارجي.

لا ، أنت تريد التحقق من _ all_ الاتصال. تحقق من الشهادة الموقعة ذاتيًا! تحقق من حصولك على الشهادة التي كنت تتوقع الحصول عليها. يجب اعتبار verify=False منهجًا ثقيلًا للأمن ، حيث يقول بشكل فعال "أمان اللولب ، فقط اجعله يعمل". هذا جيد تمامًا ، لديك الحق في أن تقول ذلك ، لكن لدينا التزامًا بأن نعتبره غير آمن.

لا أعتقد أن أيًا من الخيارين جيد ، لكن الخيار الأول أسوأ ، لأنه يعطي إنذارات خاطئة.

الخيار 1 لا يعطي إنذارات كاذبة ، إنه يعطي إنذارات حقيقية. يعتبر الاتصال إلى 10.0.0.1 "غير آمن" ، ولا ينبغي لنا أن نتظاهر بخلاف ذلك.

إذا كنت سأفعل ذلك باستخدام برنامج نصي شيل ، فسيكون المستخدم أكثر سعادة وأمانًا.

قد يكون المستخدم أكثر سعادة ، لكنه لن يكون أكثر أمانًا. سيكونون آمنين تمامًا كما كانوا من قبل. يبدو أنك تحت الانطباع بأن إيقاف تشغيل هذا التحذير بطريقة سحرية يجعل التحقق من الشهادة يختفي ، ولا يحدث. سأتطرق إلى هذا مرة أخرى في نهاية هذا الرد.

بالنسبة لي ، من المنطقي فقط إعطاء تحذير في حالة تعطل تكوين منصة Python.

لا ، يجب أن نفشل بشدة في حالة تعطل تكوين نظام Python الأساسي ولم تطلب طلبات لم يتم التحقق منها. إذا كان النظام الأساسي الخاص بك لا يمكنه إجراء اتصالات TLS آمنة ، فلا ينبغي لنا مطلقًا أن نقوم بها ، باستثناء الحالة التي يخبرنا فيها مستخدمنا صراحةً بعدم الاهتمام (من خلال تعيين verify=False ) ، وفي هذه الحالة يجب أن نحذر من ذلك ما كنت على وشك القيام به أمر خطير.

أعتقد أنك تعمل في ظل سوء فهم ، لذا أود أن أوضح شيئًا شديد الوضوح: لا توجد طريقة لتقديم طلب HTTPS غير محقق مع الطلبات بدون أ) إعداد verify=False (سلوكنا التحذيري) أو ب) تخريب وحدة ssl عمدًا. لا يمكننا الإمساك ب) ولا نحذر منه. هذا هو الموقف الوحيد الذي يندرج تحت الفكرة التي أثارتها حول "مشاكل المنصة". لا تنطبق النصائح الواردة في صفحة تعليمات urllib3 علينا لأننا نتخذ جميع الخطوات الضرورية المتعلقة بالنظام الأساسي ، بما في ذلك تجميع الشهادات الموثوقة والتحقق يدويًا من الشهادات.

هناك طريقة عرض خطيرة في مجتمع الويب مفادها أنه يجب عليك فقط التحقق من الشهادات الموقعة من خلال الشهادات الجذرية الموثوقة. هذا الرأي مضلل تماما. إذا كنت تواجه شهادات موقعة ذاتيًا ، فيجب عليك التحقق من صحتها جيدًا. هذا ممكن تمامًا! أضف الشهادة الموقعة ذاتيًا إلى ملف .pem وقم بتمريرها كوسيطة إلى verify !

إذا كنت تواجه مشكلة في دمج ذلك مع الملف المجمّع .pem ، فيرجى إبلاغي بذلك وسأعمل على تحسين mkcert.org لتمكينك من ربط شهاداتك بالجذور الموثوقة. لكن من فضلك ، لا تتظاهر بأن إعداد verify=False آمن: إنه ببساطة ليس كذلك.

أيضًا ، يؤدي تشغيل التحذير لتلك الطلبات التي يتم فيها إيقاف تشغيل التحقق صراحة من قبل المستخدم أيضًا إلى إخفاء الطلبات التي يرغب المستخدم في تحذيرها ، حيث يتم إعطاء التحذير مرة واحدة فقط.

هذا أيضا محير بعض الشيء. من خلال تعيين verify=False ربما تقوم بإيقاف تشغيله بشكل صريح لهذا الطلب فقط ، ولكن لا توجد طريقة لإيصال ذلك إلى ما بعد النقطة التي نبني فيها طلبنا. لا يوجد أيضًا سبب لنقلها إلى ما بعد تلك النقطة لأنك عطلت التحقق من الشهادة. السياق الذي فعلت فيه ذلك ليس له أي تأثير علينا أو لأي شخص يستخدم تطبيقك.

ما تطلب منا القيام به هو نفس مطالبة بائعي المستعرضات بالسماح للمستخدمين بإيقاف هذا التحذير الأحمر لعناوين URL معينة ، وأنا أضمن أنهم سيرفضون القيام بذلك لأن الآثار الأمنية وحشية.

تسمح لي المستعرضات الخاصة بي بقبول شهادة لم يتم التحقق منها بشكل دائم ، وهي "غير آمنة بشكل فظيع".

الاتصال إلى 10.0.0.1 غير آمن ، ولا ينبغي لنا أن نتظاهر بخلاف ذلك.

الاتصال غير آمن لأنه لا يمكنك التحقق من شهادة رقمية ، لكن التحقق من الشهادة لا يخبرك حقًا ما إذا كان الخادم الذي تتحدث إليه آمنًا أم لا. ولكن عندما أتحدث إلى خادم في شبكة مغلقة ، يمكنني حقًا التأكد من أمان الخادم.

أعتقد أنك تعمل في ظل سوء فهم ، لذا أود أن أوضح شيئًا شديد الوضوح: لا توجد طريقة لتقديم طلب HTTPS غير محقق مع طلبات بدون إما أ) إعداد التحقق = خطأ (سلوكنا التحذيري) أو ب) عمدًا تخريب SSL

أحاول أن أتساءل كيف يمكنني أن أكون مواطنًا صالحًا في الوحدة الخاصة بي من خلال احترام رغبة المستخدم في تجاهل عمليات التحقق من الشهادات والتحذيرات لعنوان URL الذي قدموه لي. وما القيمة التي يضيفها نموذج التحذير. ما هي الحالة التي يجب أن يظهر فيها طلب verify=False تحذيرًا للمستخدم؟

لا أرى كيف يمكن لآلية التحذير أن تلتقط رمزًا مهملاً ، لأنها لا تستطيع التمييز بين ما إذا كان الطلب قد تم بسبب الترميز غير المتقن أو لأن المستخدم طلب ذلك. لا أعتقد أن وحدة مثل requests يجب أن تملي سياسة أمنية أيضًا. لقد فهمت أن التحذيرات عادة ما تكون موجهة للمطورين حتى يتمكنوا من إصلاح التعليمات البرمجية غير الصحيحة ، لكن هذا التحذير ليس كذلك. إذا كان التحذير مخصصًا فقط للتعليم العام للمستخدم ، فيجب أن تكون هناك طريقة سهلة للمستخدم لإخفائه.

الحصول على التحذير ليس فقط من الناحية الجمالية ، لأنه يفسد إخراج البرنامج.

لا أرى سوى القيمة السلبية للتحذير ، لذلك أقوم بإيقاف تشغيله في الوحدة النمطية الخاصة بي حتى لو كنت أكره إخفاء مثل هذا التغيير في السياسة العالمية هناك.

هناك طريقة عرض خطيرة في مجتمع الويب مفادها أنه يجب عليك فقط التحقق من الشهادات الموقعة من خلال الشهادات الجذرية الموثوقة. هذا الرأي مضلل تماما.

لم أكن أعرف أن هناك منظرًا كهذا. الشهادة الموقعة بواسطة شهادة الجذر لا تثبت حقًا أي شيء يتعلق بأمان الموقع. من الرخيص الحصول على شهادة مجهولة إذا كنت تريد القيام بأشياء سيئة.

إذا كنت تواجه شهادات موقعة ذاتيًا ، فيجب عليك التحقق من صحتها جيدًا. هذا ممكن تمامًا! أضف الشهادة الموقعة ذاتيًا إلى ملف .pem وقم بتمريرها كوسيطة للتحقق!

سيحتاج المستخدم إلى قناة آمنة للحصول على الشهادة ، مثل شبكة داخلية موثوقة. ولكن إذا كان الخادم هو نفسه في نفس الشبكة الداخلية ، فلن يكون هناك الكثير من المكاسب. ولكن هذا شيء يقرره المستخدم على أي حال ، ولا يمكنني فرض سياسة في الوحدة الخاصة بي.

أتفق مع kankri ، في الغالب. كان هذا هو القصد الأصلي للتصميم.

أقترح شيئًا - نقوم بتعطيله افتراضيًا ولكن لدينا وظيفتنا الخاصة لإعادة تمكينه ، أو توثيق كيفية تشغيله. لا أريد أن يضطر المستخدمون للخروج عن الطريق لاستخدام الكود على النحو المنشود. verify=False ميزة ، وإن لم تكن من أفضل الممارسات. هذا ليس من شأننا.

أوافق على أن verify=False هي ميزة ، لكنني لا أوافق على أنها ميزة على نفس مستوى params= أو cert= . إنها ميزة يتم تعيينها افتراضيًا على قيمة آمنة وقد يتم تعيينها على قيمة غير آمنة. إنه خيار عملاق ومغري للناس للتخلص من الأمن من النافذة من أجل المنفعة ، وأعتقد أن هذا الدافع يجب أن يُقاوم (لكن لا يُمنع). سأميل دائمًا نحو مدرسة التفكير "يجب أن تكون غير آمن صراحة" ، ولا يهمني إذا كان ذلك يعني الضغط على مفتاحين وليس مفتاح واحد.

بغض النظر ، هذه مكالمتك ليست مكالمتي. =)

أردت فقط أن أقول إنني أتفق مع kankri وهذا ملاحظة @ kennethreitz

تحقق = False هي ميزة ، وإن لم تكن من أفضل الممارسات. هذا ليس من شأننا.

يلخصها بشكل جيد.

بالنسبة لأولئك الذين يرغبون أيضًا في تعطيل التحذيرات ، فهذه هي كيفية القيام بذلك. تحتاج إلى استخدام وحدات التحذيرات ، وهي جزء من المكتبة القياسية:

import warnings
import requests
from requests.packages.urllib3 import exceptions

with warnings.catch_warnings():
    warnings.simplefilter("ignore", exceptions.InsecureRequestWarning)
    warnings.warn('a non-requests warning is not blocked')
    print requests.get('https://rsa-md5.ssl.hboeck.de/', verify=False)

يؤدي هذا إلى تكوين عامل تصفية تحذير يتجاهل أي تحذير من الفئة InsecureRequestWarning . يبدو الإخراج كما يلي:

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

(يحدث أن يعرض موقع الاختبار صفحة 403 محظورة ، لكن هذا ليس مهمًا هنا.)

لاحظ أنك تحتاج إلى استخدام الفئة من الحزمة المجمعة urllib3 ، وليس الفئة من حزمة المستوى الأعلى urllib3 ، إذا كان لديك واحدة مثبتة.

يمكنك (وربما ينبغي) إنشاء وظيفة صغيرة تستخدم مدير السياق في أصغر منطقة ممكنة من التعليمات البرمجية:

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

أو قم بهذا ببساطة:

requests.packages.urllib3.disable_warnings()

تضمين التغريدة

أو قم بهذا ببساطة:

requests.packages.urllib3.disable_warnings()

إلا أنني لم أجد أي ذكر لهذه الوظيفة في دليل الطلبات.

على الرغم من أنه بعيد عن كل من يعرف عنها ، إلا أنني أزعم أن الوحدة النمطية warnings _ هي الأداة القياسية التي يجب أن يبحث عنها مبرمج Python عندما يريد تعطيل التحذيرات. إنه جزء من المكتبة القياسية وموثق جيدًا.

أقترح وضع مرجع إلى warnings في وثائق requests - أو إلى الوظيفة الملائمة disable_warnings إذا أردت ، طالما أن هناك enable_warnings وظيفة ( يبدو أنه لا توجد مثل هذه الوظيفة ).

مرة أخرى: لا أريد تعطيل التحذيرات بشكل عام. أريد فقط أن يختفي هذا التحذير تحديدًا عندما أقوم بتعيين التحقق = خطأ في الكود الخاص بي. قد تكون هناك تحذيرات أخرى ، مفيدة ، بخلاف هذا التحذير المحدد غير المجدي. ما الذي يصعب فهمه عن هذا ؟!

zaitcev في خطر تكرار نفسي:

requests.packages.urllib3.disable_warnings()

وحتى إذا كان هذا واسعًا جدًا بالنسبة لك:

from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

أخيرًا ، ملاحظة ، zaitcev : ستجد أن يفيدك على الإطلاق. تذكر أننا جميعًا متطوعون ، وأن لدينا قدرًا محدودًا من وقتنا لنمنحه لبناء الأشياء لك. يرجى محاولة معاملتنا بالطريقة التي تحب أن تعاملنا بها.

zaitcev لا يبدو أن هذا سيتغير في وحدة الطلبات نفسها ، لكن آمل أن تتمكن من استخدام الكود الذي وضعته في تعليقي الآخر . يجب أن يسمح لك ذلك بتعطيل التحذيرات المنبعثة من urllib3 بشكل انتقائي.

يمكنك أيضًا قمعه باستخدام:

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

في حالتي ، لا أستخدم الطلبات بشكل مباشر ، لذا فإن قمع مثل هذا يجعلني أقلق قليلاً بشأن الانهيار لاحقًا.

zaitcev عند جمع كل الاقتراحات السابقة معًا ، يمكنك القيام بشيء مثل هذا:

verify = False
if not verify:
    from requests.packages.urllib3.exceptions import InsecureRequestWarning
    requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
r = requests.get('https://www.example.com', verify=verify)

utkonos سيؤدي ذلك إلى تعطيل التحذيرات لجميع الطلبات اللاحقة.

بوضع أمثلة أخرى معًا ، قمت بتوسيع Session الافتراضي (مثل requests.get وأنشئ الاختصارات الأخرى Session مؤقتًا ، على أي حال):

from requests.packages.urllib3 import exceptions

class Session(requests.sessions.Session):

    def request(self, *args, **kwargs):
        if not kwargs.get('verify', self.verify):
            with warnings.catch_warnings():
                warnings.simplefilter('ignore', exceptions.InsecurePlatformWarning)
                warnings.simplefilter('ignore', exceptions.InsecureRequestWarning)
                return super(Session, self).request(*args, **kwargs)
        else:
            return super(Session, self).request(*args, **kwargs)

من المحتمل أن يكون تعطيل جميع التحذيرات من requests فكرة سيئة ، وربما يكون الأفضل قليلاً:

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

لتلخيص كيف تعاملت مع هذا:

import warnings
with warnings.catch_warnings():
    warnings.simplefilter("error") 
    try:
        req = requests.get("https://an-insecure-server.com")
    except (RuntimeWarning, requests.exceptions.SSLError)::
        log.error("Making an insecure request")
        warnings.simplefilter("ignore")
        req = requests.get("https://an-insecure-server.com")

هذا يسمح لي بالتحقق مما إذا كان الطلب غير آمن ، وإخفاء تحذير urllib ورفع تحذير من التنسيق الخاص بي للمستخدم. لا يتطلب أن يتم تقديم الطلب مرتين. تم تعديله لجعل بند "الاستثناء" أقل شمولاً.

except Exception: واسع جدًا. أنت حقا لا تريد ذلك.

ما ورد أعلاه يذهب إلى حد ما لمعالجة المخاوف على جانبي هذه المناقشة.

ألا يرمي بعض الفئات الفرعية من الاستثناءات التي يمكنك التقاطها بدلاً من ذلك؟

أو استخدم logging.captureWarnings()

البديل هو معرفة أن urllib3 متورط وترميز مساحة الاسم الخاصة به ، انظر تعليق tuukkamustonen. كان هذا اعتراضي الرئيسي: كان بإمكانهم جعل الأمر يعمل بشكل صحيح ، حتى أنني قدمت تصحيحًا في طلب السحب. لكنهم ينكرون وجود المشكلة ويطلبون من جميع المستخدمين أن يتوصلوا إلى حلول رهيبة مثل "باستثناء استثناء" أو "من استثناءات استيراد request.packages.urllib3". في هذه المرحلة ، يجب على شخص ما أن يعترف بأنه كان مخطئًا طوال الوقت ولذا نحن عالقون.

كان هذا اعتراضي الرئيسي: كان بإمكانهم جعل الأمر يعمل بشكل صحيح ، حتى أنني قدمت تصحيحًا في طلب السحب. لكنهم ينكرون وجود المشكلة ويطلبون من جميع المستخدمين أن يتوصلوا إلى حلول رهيبة مثل "باستثناء استثناء" أو "من استثناءات استيراد request.packages.urllib3". في هذه المرحلة ، يجب على شخص ما أن يعترف بأنه كان مخطئًا طوال الوقت ولذا نحن عالقون.

zaitcev مرة أخرى ، اسمحوا لي أن أذكرك أن هذا مجتمع تطوعي يبذل قصارى جهده. لقد تركنا هذه المسألة مجانية للمناقشة ، ولم نحاول قفلها أو منع إجراء مزيد من المناقشة. نحن _ نستمع اليك_. ما لا نفعله هو الموافقة على الفور على تقييمك للوضع. يرجى النظر في إمكانية اهتمامنا بحالات استخدام أكثر من مجرد حالاتك ، وأننا بحاجة إلى الموازنة بين احتياجاتهم جميعًا.

بالنسبة لطلب السحب الخاص بك ، فقد تم رفضه لسبب محدد للغاية تتجاهله باستمرار! اسمحوا لي أن أقتبس نفسي من إيان :

كان البيان الختامي: "نظرًا لأن هذا في الغالب في urllib3 وسيعتمد على القبول هناك ، فأنا أغلق هذا حتى يتم إحراز تقدم هناك. " (أؤكد لي).

حتى اليوم ما زلت لا أرى أي طلب أو مشكلة سحب مرتبطة بهذه المشكلة في urllib3. لم يقف أي شخص من هذا المشروع في طريقك أو منع حدوث هذا العمل ، فنحن ببساطة لم نختار القيام بذلك بأنفسنا لأننا _ لا نتفق معك حاليًا_.

ومع ذلك ، مع خطر النزول في حفرة الأرانب هذه مرة أخرى ، اسمحوا لي أن أكرر:

كان هذا اعتراضي الرئيسي: كان بإمكانهم جعله يعمل بشكل صحيح.

لا أعتقد أن رقعتك تجعل هذا العمل "صحيحًا" . كما قلت مرات عديدة في هذا الموضوع ، أرى أن السلوك الحالي مرغوب فيه. يعد إجراء طلبات TLS غير الآمنة فكرة سيئة ، ويجب تحذير المستخدمين من القيام بذلك.

موقفي هو أن المستخدم _يجب أن يعرف_ عندما يقدم طلب TLS غير مؤمن بشكل كافٍ ، لا سيما في أي نظام يتعامل مع كلمات المرور الخاصة به.

هناك اتفاق في هذا الموضوع على أنه يجب علينا التفكير في وجود رابط على مستوى الطلبات لتعطيل هذه التحذيرات. من ناحية أخرى ، لا أحد حاليًا ولكنك تعتقد أن بعض الفروق غير الموجودة سابقًا بين verify=False و verify=None يجب إضافتها لإسكات هذه التحذيرات ضمنيًا. سوف تجد أنه من الأسهل بكثير القيام بالأولى من الثانية.

+1 لعدم التفريق بين تحقق = خطأ وتحقق = لا شيء. سأدعم إما:

• إضافة معلمة جديدة (على سبيل المثال ، noInsecureWarnings) ، أو
• وجود طلبات لاعتراض تحذير urllib3 وإصدار واحد خاص به ، لذلك (أ) يمكنني منع شيء أقل رعبًا من الاستثناءات من "طلبات حزم. إلى مكتبة أساسية مختلفة) ، و (ب) يمكن أن يشير التحذير إلى عنوان URL خاص بالطلبات (عنوان URL الحالي ليس ذا صلة حيث تم تظليل التحذير!)

وبفضل جميع المتطوعين لدعم الطلبات ، سواء تم إصلاح ذلك أم لا: إنها مكتبة رائعة :)

هذه مكتبة رائعة ، شكرا لكل عملك الشاق.

لقد تعاملت مع هذه المشكلة بعد ترقية حزم python الخاصة بي مؤخرًا ولاحظت عددًا كبيرًا من مطبوعات InsecurePlatformWarning الجديدة. لذلك أنا أساهم بحالة الاستخدام الخاصة بي ، والتي أعتقد أنها مقنعة.

أنا أستخدم الطلبات لإدارة خوادم jenkins عبر 4 بيئات مختلفة. ثلاث بيئات (مطور ، مرحلي ، إنتاج) جميعها لديها شهادات صالحة. البيئة الرابعة عبارة عن صندوق افتراضي متشرد ، يمكن للمطورين استخدامه لاختبار التغييرات على أجهزتهم المحلية. لا يحتوي هذا على شهادة صالحة ، ولكن كسياسة ، ترفض جميع تكوينات الخادم الطلبات غير المشفرة.

تتضمن إعدادات اتصال jenkins (اسم الخادم ، الرمز المميز ، إلخ) لبيئة ما علامة محددة لإيقاف تشغيل التحقق من SSL ، والذي تم تعيينه فقط على True من أجل بيئة المتشرد.

في الإعداد الخاص بي ، يعد تعطيل التحذير على مستوى العالم فكرة سيئة لأن المشروع كبير نوعًا ما وقد يتم تقديم الكثير من الطلبات ، مع مكتبة الطلبات أو بدونها. سيكون تعطيل التحذير في النطاق أمرًا جيدًا ، باستثناء جزء من المشروع يتضمن تطبيق قارورة وحالات أخرى محتملة متعددة الخيوط.

في رأيي ، يبدو أن استخدام التحقق = False يجب أن يتم دعمه والعمل كما هو متوقع ، دون تحذيرات. الأمر متروك لمطور التطبيق ليقرر متى وما إذا كان ينبغي السماح بذلك. على سبيل المثال ، إذا كنت أكتب متصفحًا للاستخدام العام ، فلن أقوم أبدًا بتعيين هذا على True بدون عرض مربع حوار تأكيد كبير به الكثير من النص الأحمر. ولكن إذا كنت أمتلك الخادم والعميل ولدي أسباب خاصة بي لعدم إصدار شهادة ، فيجب أن أكون قادرًا على الحصول على سجل نظيف وعدم إخفاء المشكلات المحتملة الأخرى.

الأمر متروك لمطور التطبيق ليقرر متى وما إذا كان ينبغي السماح بذلك.

هذا الخلاف هو حيث أختلف معك. أعتقد أن الأمر متروك للمطور ليقرر متى يجب استخدامه. لكنني أعتقد أن الأمر متروك للمستخدم ليقرر ما إذا كان هذا الاختيار مقبولاً. من الأهمية بمكان أن يفهم المستخدمون متى يتم تعريضهم للخطر من خلال اختيارات المطورين ، وأن يكونوا قادرين على تقييم هذا الخطر.

ولكن إذا كنت أمتلك الخادم والعميل ولدي أسباب خاصة بي لعدم إصدار شهادة ، فيجب أن أكون قادرًا على الحصول على سجل نظيف وعدم إخفاء المشكلات المحتملة الأخرى.

ويمكنك القيام بذلك ، باستخدام مدير سياق التسجيل لالتقاط التحذير. نحن نفكر أيضًا في وجود طلبات تجعل هذا التحذير أكثر تحديدًا للطلبات حتى يسهل التقاطه ، لكن هذا لم يحدث بعد.

لدي حالة مشابهة لـ @ jamie-sparked.

أنا أفهم وجهة نظر Lukasa في فرض الأمان ، لكن أعتقد أنه يجب عليك السماح للمستخدم بتحديد الأفضل بالنسبة له.
الطلبات عبارة عن مكتبة وليست تطبيق مستخدم نهائي. IMO يجب أن تعتبر المطورين مستخدمين لك.
يجب أن يكون مطورو التطبيقات مسؤولين عن أخطاء الأمان ، إذا قرروا إيقاف التحقق من الشهادة (أي التحقق = خطأ)

بصفتي مطورًا ، فأنا أقدر المرونة على مكتبة تحاول إملاء ما يجب علي فعله.

راجع للشغل كما قال الآخرون ، أجد طلبات _ممتازة_ وأنا أقدر كل جهودك. شكرا.

thalesac نحن _do_ ندع المطورين يقررون. كما تمت مناقشته _عدة مرات_ في هذا الموضوع ، من الممكن تمامًا إيقاف تشغيل هذا التحذير. ومع ذلك ، ليس لدينا مفتاح واحد يقوم بإيقاف تشغيل جميع التحذيرات: تحتاج إلى القيام بكل منها يدويًا. هذه محاولة لجعل مستخدمينا _ بوعي_ يزيلون كل حارس أمان.

فكر في الأمر على أنه دفاع متعمق. لاستخدام تشبيه المسدس ، نسلمك مسدسًا مع الأمان ولا يوجد رصاص فيه ، ومجلة. إذا كان لدينا verify=False تعطيل جميع التحذيرات ، فسيكون ذلك مكافئًا لامتلاك مسدس ، عند إدخال المجلة ، يقوم تلقائيًا بتعطيل الأمان وتثبيته في غرفة. مناسب؟ بالتأكيد. خطير >> صفة؟ تتحدى.

أنا خائف ، أنا لا أتفق مع نموذج القياس الخاص بك.
أود أن أقول التحقق = False هي آلية الأمان / الأمان الخاصة بك. إذا قمت بتعطيله صراحة (أو يدويًا) ، فأنت لا تريد أن تحذرك البندقية طوال الوقت عندما تطلق النار على الأشرار. من الواضح أن السلوك الافتراضي يجب أن يفرض الفكر الأمني.
على أي حال ، أنا أفهم أن هذا مجرد وجهة نظري ويجب أن تفعل ما تعتقد أنه الأفضل لمشروعك. ربما لهذا السبب هي مكتبة جيدة. :)
شكرا

أنا أتفق بالتأكيد مع Lukasa ، فالأمان هو أول شيء ، وإذا كنت كمطور أستخدم check = False في جزء واحد من الكود الخاص بي ، فيجب علي إلغاء التحذير ، إذا كنت لا أريد أن يتم تحذيري.

على أي حال مكتبة كبيرة من المعجبين بعمل فريقك ، استمروا في ذلك ، +10000 للصبر للرد علينا.

بالطريقة التي أراها ، إذا كان أحد التطبيقات يستخدم عنوان url تم تعيينه بواسطة مستخدم ، فيجب تزويد المستخدم بخيار لتعطيل التحقق ولكن في كل موقف يمكنني التفكير فيه يجب أن يحصلوا على التحذير. إذا كنت كمطور وتعرف لأي سبب من الأسباب ، فأنت تتصل بعنوان url الذي لا يُتوقع أن يكون لديك شهادة صالحة (خدمات داخلية لن تدفع مقابل الحصول على شهادة ، أو اختبار ، إلخ) ، فيجب أن يكون لديك خيار التعطيل التحذيرات مع تعطيل التحقق.

في الوقت نفسه ، لا أعتقد أنه سيكون من الشائع أن يكون لديك موقف تريد فيه تعطيل التحذيرات عالميًا دفعة واحدة لأن ذلك يجعل من السهل جدًا فتح مشكلات الأمان التي يتم تجاهلها بصمت.

requests.packages.urllib3.disable_warnings() نعم إنه عمل

أهلا

هل requests.packages.urllib3.disable_warnings() لا يعمل بعد الآن؟ اعتادت إسكات التحذيرات بالنسبة لي. هذا هو المكان الذي أستدعي فيه وظيفة تحذيرات التعطيل ، وهنا مثال على التتبع الخلفي حيث يتم استدعاء وظيفة التحذير:

 [+] إعادة توجيه مقبولة إلى https://drupal.org/
 > /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py (791) _validate_conn ()
 -> تحذيرات. تحذير ((
 (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 ()
 -> وظيفة الإرجاع ()
 /usr/local/lib/python2.7/dist-packages/cement/core/controller.py (472) _dispatch ()
 -> وظيفة الإرجاع ()
 /root/droopescan/dscan/plugins/internal/scan.py (114) افتراضي ()
 -> follow_redirects)
 /root/droopescan/dscan/plugins/internal/scan.py (230) _process_cms_identify ()
 -> إذا inst.cms_identify (url ، يختار ['timeout'] ، self._generate_headers (host_header)) == صحيح:
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py (910) cms_identify ()
 -> رؤوس)
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py (827) enumerate_file_hash ()
 -> r = self.session.get (url + file_url ، timeout = timeout ، headers = headers)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (480) get ()
 -> return self.request ('GET' ، url ، ** kwargs)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (468) طلب ()
 -> resp = self.send (الإعدادية ، ** send_kwargs)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (576) send ()
 -> r = adaptor.send (request، ** kwargs)
 /usr/lib/python2.7/dist-packages/requests/adapters.py (376) send ()
 -> المهلة = المهلة
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py (559) urlopen ()
 -> body = body ، headers = headers)
 /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 ()
 -> تحذيرات. تحذير ((

التالي هو ناتج pip freeze ، أنا أستخدم اختبار Debian:

 argparse == 1.2.1
 beautifulsoup4 == 4.4.1
 الاسمنت == 2.6.2
 chardet == 2.3.0
 colorama == 0.3.3
 التغطية == 4.0.3
 التشفير == 1.2.1
 Distlib == 0.2.1
 -e [email protected]: droope/droopescan.git@6524a9235e89a6fdb3ef304ee8dc4cb73eca0386#egg=droopescan-development
 enum34 == 1.1.2
 funcsigs == 0.4
 العقود الآجلة == 3.0.4
 html5lib == 0.999
 HTplib2 == 0.9.1
 idna == 2.0
 ipaddress == 1.0.16
 lxml == 3.5.0
 زئبقي == 3.5.2
 وهمية == 1.3.0
 ndg-httpsclient == 0.4.0
 أنف == 1.3.7
 pbr == 1.8.1
 pyOpenSSL == 0.15.1
 pyasn1 == 0.1.9
 بيكورل == 7.21.5
 pystache == 0.5.4
 python-apt == 1.1.0b1
 python-debian == 0.1.27
 python-debianbts == 2.6.0
 reportbug == 6.6.6
 الطلبات == 2.9.1
 الردود == 0.3.0
 إعادة المحاولة == 1.3.3
 ستة == 1.10.0
 urllib3 == 1.13.1
 عجلة == 0.26.0
 wsgiref == 0.1.2

شكرا،
بيدرو

disable_warnings لا يمنع استدعاء وظيفة التحذير ، بل يقوم فقط بإيقاف الإخراج. قد تواجه مشاكل إذا كان جزء آخر من التعليمات البرمجية يمكّن جميع التحذيرات.

مرحبًا Lukasa ،

أضع نقطة التوقف بعد إذا. في النهاية توقفت عن استخدام اختبار دبيان لأنني واجهت العديد من المشكلات ، وقد يكون هذا أحد هذه المشكلات. أود فقط تجاهل تعليقي ، لست متأكدًا مما حدث ولكن من المحتمل ألا يكون شيئًا سيؤثر على الكثير من الناس.

شكرا!
بيدر

أجل ، إذا كنت تستخدم حزمة من دبيان ، فمن الممكن أن يكون منطقهم غير المتميز قد كسر شيئًا ما هنا.

إن الرغبة في تقديم طلب غير آمن عن طريق تحديد verify=False وعدم رؤية تحذير لهذا الطلب ، دون التدخل في التحذيرات لأي طلبات أخرى يتم تقديمها في مكان آخر ، يبدو معقولًا تمامًا.

from requests.packages.urllib3.exceptions import InsecureRequestWarning

...
with warnings.catch_warnings():
    warnings.filterwarnings("ignore", category=InsecureRequestWarning)
    resp = requests.get(url, verify=False)  # InsecureRequestWarning suppressed for this request

resp = requests.get(url, verify=False)  # InsecureRequestWarning not suppressed for this request
...