Requests: एसएसएल क्लाइंट साइड सर्टिफिकेट के लिए पासवर्ड निर्दिष्ट करें

कुछ इस तरह:

requests.get('https://kennethreitz.com', cert='server.pem', cert_pw='my_password')

निश्चित रूप से आपको इसके लिए cert परम का उपयोग करना चाहिए: cert=('server.pem', 'my_password')

@sigmavirus24
टपल (certificate, key) । वर्तमान में एन्क्रिप्टेड कीफाइल्स के लिए कोई समर्थन नहीं है।
Stdlib को केवल संस्करण 3.3 में उन लोगों के लिए समर्थन मिला।

अरे, @ t-8ch, आप गलती से अपने स्थानीय FS पर एक फ़ाइल से जुड़ गए। ;) सही लिंक ।

बिल्कुल सही @ t-8ch। इसलिए मुझे कभी भी बस के मुद्दों का जवाब नहीं देना चाहिए। :/

इसलिए वर्तमान आम सहमति यह है कि हम इसका समर्थन नहीं करते हैं। पायथन के गैर-3.3 संस्करणों में समर्थन जोड़ने में कितना काम होने की संभावना है?

इस स्थिति में त्रुटि फेंकना कितना कठिन होगा? मैं बस इस मूर्खतापूर्ण समस्या में भाग गया और यह पता लगाने में दो घंटे लग गए, यह अच्छा होगा अगर यह एक त्रुटि फेंक देगा, यह वर्तमान में वहां लूपिंग करता है। शानदार पुस्तकालय के लिए धन्यवाद!

रुको, यह लूपिंग कहाँ बैठता है? निष्पादन में हम कहाँ असफल होते हैं? क्या आप ट्रेसबैक प्रिंट कर सकते हैं जहां से हम लूप करते हैं?

ऐसा लगता है कि यहीं लटका हुआ है:

आर = अनुरोध। प्राप्त करें (यूआरएल,
प्रमाणीकरण = शीर्षलेख,
सर्टिफिकेट = सेल्फ.सर्ट_टुपल,
हेडर = हेडर,
समय समाप्त = १०,
सत्यापित करें = सत्य)

मैंने बिना किसी लाभ के टाइमआउट को ऊपर या नीचे करने की कोशिश की, लेकिन मुझे लगता है कि यह टाइमआउट से पहले अच्छी तरह से जानता है कि यह प्रमाण का उपयोग नहीं कर सकता है। धन्यवाद!

आह, क्षमा करें, मैं स्पष्ट नहीं था। मेरा मतलब था कि इसे लटका दें और फिर इसे Ctrl + C से मार दें ताकि अजगर एक कीबोर्डइंटरप्ट अपवाद फेंके, फिर यह देखने के लिए कि हम ट्रेसबैक में कहां हैं। मैं जानना चाहता हूं कि अनुरोधों में निष्पादन कहां रुकता है।

क्या हो रहा है (या कम से कम जो मैंने कई मामलों में देखा है) वह यह है कि ओपनएसएसएल, पासवर्ड-संरक्षित प्रमाणपत्र दिए जाने पर, उपयोगकर्ता को पासवर्ड के लिए संकेत देगा। यह बिना लॉग में दिखाई देता है (क्योंकि प्रॉम्प्ट सीधे मुद्रित होता है), और यह समय समाप्त नहीं होता है क्योंकि यह उपयोगकर्ता द्वारा एंटर दबाए जाने की प्रतीक्षा कर रहा है।

कहने की जरूरत नहीं है, जब सर्वर पर कोड चल रहा होता है तो यह बोझिल, खतरनाक व्यवहार होता है (क्योंकि यह आपके कार्यकर्ता को प्रक्रिया को मारने के अलावा पुनर्प्राप्ति के लिए कोई विकल्प नहीं देगा)।

क्या पासवर्ड के लिए अनुरोध करने के बजाय अनुरोध करने का कोई तरीका है, या यह पूरी तरह से आपके नियंत्रण से बाहर है और ओपनएसएसएल के हाथों में है?

@maxnoel मुझे पूरा यकीन है कि यह ओपनएसएसएल के हाथों में है, लेकिन अगर आप @लुकासा के सवाल का जवाब दे सकते हैं (इस मुद्दे पर आखिरी टिप्पणी) तो यह निश्चित जवाब देने में बहुत मददगार होगा कि क्या कुछ है जो हम मदद करने के लिए कर सकते हैं .

आप पुष्टि कर सकते हैं कि ओपनएसएसएल इंटरएक्टिव पायथन प्रॉम्प्ट से पासफ़्रेज़ के लिए स्टड पर ब्लॉक कर रहा है:

>>> r = requests.get("https://foo.example.com/api/user/bill", cert=("client.crt", "client.key"))
Enter PEM pass phrase:
>>>

यदि आप पृष्ठभूमि वाली प्रक्रिया से चल रहे हैं, तो मुझे लगता है कि ओपनएसएसएल उस इनपुट पर प्रतीक्षा कर रहा है।

यह सही है। क्या ऐसा होने से रोकने के लिए कोई अनुरोध किया जा सकता है? जब कोई पासवर्ड नहीं दिया जाता है तो अपवाद उठाना स्टड पर सामान के लिए संकेत देने से कहीं अधिक उपयोगी होगा (विशेषकर एक गैर-संवादात्मक कार्यक्रम में)।

मुझे डर है कि मुझे कोई रास्ता नहीं पता। @रीपरहल्क?

ओपनएसएसएल को ऐसा करने से रोकने के कई तरीके हैं, लेकिन मुझे यकीन नहीं है कि वे pyOpenSSL द्वारा उजागर किए गए हैं। क्लाइंट प्रमाणपत्र लोड करने के लिए अनुरोध pyopenssl को कहां कॉल करता है? मैं थोड़ा खोद सकता हूँ।

@reaperhulk यह यहां urllib3 से किया गया

हम stdlib के लिए भी कुछ ऐसा ही करते हैं, जो एक पूरी तरह से अलग समस्या होगी।

इसलिए हम pyOpenSSL की तरह एक पैच का उपयोग कर के साथ ऐसा कर सकते हैं इस । Stdlib संस्करण में, हमें पासवर्ड के साथ load_cert_chain का उपयोग करने की आवश्यकता है।

क्या यह समस्या हल हो गई है? मैं वर्तमान में अपाचे सर्वर से कनेक्ट करने का प्रयास करते समय इसमें भाग रहा हूं।

यह नहीं है।

PKCS#12 स्वरूपित (और एन्क्रिप्टेड) ​​कंटेनरों के बारे में क्या जिनमें क्लाइंट प्रमाणपत्र/कुंजी हो सकती है? क्या यह उसी सुविधा अनुरोध के अंतर्गत आएगा?

@ मिकेलुपो हाँ।

@telam @mikelupo
मुझे एक ही समस्या है और बहुत गुगल किया, आखिरकार, मैंने इसे pycurl का उपयोग करके हल किया।
मेरी स्थिति में, मैं अपनी .pfx फ़ाइल को .pem फ़ाइल में कनवर्ट करने के लिए ओपनएसएल का उपयोग करता हूं जिसमें प्रमाणपत्र और कुंजी (पास वाक्यांश के साथ एन्क्रिप्टेड) ​​दोनों शामिल हैं, फिर निम्न कोड का आह्वान करें।

import pycurl
import StringIO

b = StringIO.StringIO()
c = pycurl.Curl()
url = "https://example.com"
c.setopt(pycurl.URL, url)
c.setopt(pycurl.WRITEFUNCTION, b.write)
c.setopt(pycurl.CAINFO, "/path/cacert.pem")
c.setopt(pycurl.SSLKEY, "/path/key_file.pem")
c.setopt(pycurl.SSLCERT, "/path/cert_file.pem")
c.setopt(pycurl.SSLKEYPASSWD, "your pass phrase")
c.perform()
c.close()
response_body = b.getvalue()

BTW, सुरक्षा के लिए, pass phrase लिए हार्डकोड नहीं करना बेहतर है

बेशक। उस ने कहा, समस्या वास्तव में यह नहीं है कि एक पास वाक्यांश की आवश्यकता है - यह है कि ओपनएसएसएल आपके प्रोग्राम को हैंग कर देता है, जबकि कोई व्यक्ति स्टड में पासफ़्रेज़ टाइप करने की प्रतीक्षा कर रहा है, यहां तक ​​​​कि एक गैर-संवादात्मक, जीयूआई या रिमोट प्रोग्राम के मामले में भी।

जब पासफ़्रेज़ की आवश्यकता होती है और कोई भी प्रदान नहीं किया जाता है, तो इसके बजाय एक अपवाद उठाया जाना चाहिए।

यदि आप कुंजी के लिए '' के डिफ़ॉल्ट पासफ़्रेज़ का उपयोग करते हैं, तो Opensl हैंग नहीं होगा।
यह एक खराब पासवर्ड टेक्स्ट लौटाएगा। आप तुरंत अपना py प्रवाह बदल सकते हैं
तब उपयोगकर्ता को उस स्पष्ट स्टाल के बिना सूचित करने के लिए

इस सुविधा को जोड़ने की कोई योजना

हम इसे जोड़ना चाहते हैं, लेकिन इस समय हमारे पास इसे जोड़ने का कोई शेड्यूल नहीं है।

@botondus मुझे लगता है कि मुझे अनुरोध पुस्तकालय के साथ इसे प्राप्त करने का एक आसान तरीका मिला। मैं इसे अन्य लोगों के लिए दस्तावेज कर रहा हूं जो इस मुद्दे का सामना कर रहे हैं।

मुझे लगता है कि आपके पास कुंजी के लिए .p12 प्रमाणपत्र और पासफ़्रेज़ है।

प्रमाणपत्र और निजी कुंजी उत्पन्न करें।

// Generate the certificate file.
openssl pkcs12 -in /path/to/p12cert -nokeys -out certificate.pem
// Generate private key with passpharse, First enter the password provided with the key and then an arbitrary PEM password //(say: 1234) 
openssl pkcs12 -in /path/to/p12cert -nocerts -out privkey.pem

ठीक है, हमने अभी तक काम नहीं किया है और हमें उस कुंजी को उत्पन्न करने की आवश्यकता है जिसके लिए सर्वर से बात करने के लिए हर बार पीईएम पासवर्ड की आवश्यकता नहीं होती है।

पासफ़्रेज़ के बिना कुंजी उत्पन्न करें।

// Running this command will prompt for the pem password(1234), on providing which we will obtain the plainkey.pem
openssl rsa -in privkey.pem -out plainkey.pem

अब, आपके पास certificate.pem और plainkey.pem , दोनों फाइलें अनुरोधों का उपयोग करके एपीआई से बात करने के लिए आवश्यक हैं।

इन प्रमाणपत्रों और कुंजियों का उपयोग करके एक उदाहरण अनुरोध यहां दिया गया है।

import requests
url = 'https://exampleurl.com'
headers = {
            'header1': '1214141414',
            'header2': 'adad-1223-122'
          }
response = requests.get(url, headers=headers, cert=('~/certificate.pem', '~/plainkey.pem'), verify=True)
print response.json()

उम्मीद है ये मदद करेगा:

cc @kennethreitz @Lukasa @sigmavirus24

मैंने अंगूर के माध्यम से सुना है कि अमेज़ॅन आंतरिक रूप से ठीक यही करता है।

मैं भी इस मुद्दे का सामना कर रहा हूं। मेरी चिंता यह है कि मैं सादे निजी कुंजी को फाइल सिस्टम में स्टोर नहीं करना चाहता (दूसरों द्वारा चोरी होने का जोखिम हो सकता है)। तो मेरी राय में, इसे लागू करने का अधिक एक्स्टेंसिबल तरीका निजी कुंजी निर्दिष्ट करने के लिए फ़ाइल पथ के बजाय PEM encoded string of private key जैसे कुछ का उपयोग करना समर्थन करना है। डेवलपर्स को उनके पक्ष में निजी कुंजी/प्रमाण पत्र के एन्क्रिप्शन/डिक्रिप्शन को बस छोड़ दिया।
अनुरोधों के स्रोत कोड को पढ़ने के बाद, ऐसा लगता है कि इसे लागू करना काफी आसान नहीं है क्योंकि अनुरोध अजगर के ssl lib पर निर्भर करता है जो केवल प्रमाणपत्र/निजी कुंजी फ़ाइल का समर्थन करता है। मैं बस सोच रहा हूं कि क्या हम पाइथन stdlib के बजाय pyopenssl का उपयोग कर सकते हैं? pyopenssl में ओपनएसएल कनेक्शन का एक आवरण है, देखें: https://pyopenssl.readthedocs.io/en/latest/api/ssl.html#connection -objects । इस प्रकार हम फ़ाइल पथ के बजाय 'pkey' ऑब्जेक्ट को निजी कुंजी के रूप में उपयोग कर सकते हैं।

अनुरोध पहले से ही PyOpenSSL का समर्थन करता है, जब तक कि यह और कुछ अन्य आवश्यक निर्भरताएँ स्थापित हैं। हालांकि, यह कभी भी अनिवार्य नहीं होगा: हमारे लिए यह महत्वपूर्ण है कि हम मानक पुस्तकालय के साथ अच्छी तरह से काम करें।

भविष्य में रिलीज में हमारे पास टीएलएस को संभालने के लिए SSLContext ऑब्जेक्ट्स को urllib3 में पास करने के लिए समर्थन होगा: जो इस फ़ंक्शन को सक्षम करेगा।

इस समस्या का सामना करने वालों के लिए, जब तक अनुरोध ssl.SSLContext/OpenSSL.SSL.Context को urllib3 में पास करने की क्षमता नहीं जोड़ता, यहां एक वर्कअराउंड है जो वास्तव में एन्क्रिप्टेड प्रमाणपत्र/कीफाइल का उपयोग करने का समर्थन करता है (इसके लिए मानक पुस्तकालय के बजाय PyOpenSSL स्थापित और उपयोग किया जाता है) ssl, जो इसे स्थापित होने पर होना चाहिए)

import requests

 # Get the password from the user/configfile/whatever
password = ...

# Subclass OpenSSL.SSL.Context to use a password callback that gives your password
class PasswordContext(requests.packages.urllib3.contrib.pyopenssl.OpenSSL.SSL.Context):
    def __init__(self, method):
        super(PasswordContext, self).__init__(method)
        def passwd_cb(maxlen, prompt_twice, userdata):
            return password if len(password) < maxlen else ''
        self.set_passwd_cb(passwd_cb)

# Monkey-patch the subclass into OpenSSL.SSL so it is used in place of the stock version
requests.packages.urllib3.contrib.pyopenssl.OpenSSL.SSL.Context = PasswordContext

# Use requests as normal, e.g.
endpoint = 'https://example.com/authenticated'
ca_certs = '/path/to/ca/certs/bundle'
certfile = '/path/to/certificate'
keyfile = '/path/to/encrypted/keyfile'
requests.get(endpoint, verify=ca_certs, cert=(certfile, keyfile))

@ahnolds : क्या यह

@ लुकासा : क्या

PKCS#12 एक पेचीदा मुद्दा है, लेकिन मूल रूप से आपको अपने SSLContext को अनुकूलित करने के लिए जो कुछ भी आवश्यक है वह करना होगा।

@ लुकासा : मैं अनुरोधों में एक अच्छा उच्च स्तरीय एपीआई प्रदान करने के बारे में और सोच रहा था। उदाहरण के लिए, केवल client_cert.p12 फ़ाइल नाम और पासवर्ड को cert=... कीवर्ड पैरामीटर के माध्यम से प्रदान करना।

@vog आपको क्या लगता है कि उस काम को करने के लिए किस कोड की आवश्यकता होगी?

@ लुकासा मैं requests के आंतरिक के बारे में निश्चित नहीं हूं, इसलिए हो सकता है कि मैं पहले से मौजूद चीज़ों को कम से कम समझूं , लेकिन मुझे लगता है कि निम्नलिखित चीजों में से एक को करने की आवश्यकता है:

• या तो हमारे पास एक PKCS#12 फ़ाइल नाम सीधे निचली परतों (urllib3, आदि) को प्रदान करने का एक तरीका है। और शायद पासवर्ड भी। (क्योंकि मैं किसी ऐसे व्यक्ति को नहीं जानता जो यूआरएल लाइब्रेरी चाहता है कि वह सर्वर-साइड चलाने वाले टूल पर अपना पीकेसीएस #12 पासवर्ड दर्ज करने के लिए अंतःक्रियात्मक रूप से व्यवस्थापक से पूछे।)
• यदि यह असंभव है, तो हमें पीकेसीएस#12 (+पासवर्ड) को पीईएम में बदलना होगा, फिर इन्हें निचले स्तरों पर उपलब्ध कराना होगा। यह कुछ कॉलों के साथ सीधे OpenSSL बाइंडिंग पर किया जाता है। हालांकि, परिणाम एक स्ट्रिंग के रूप में पीईएम प्रमाणपत्र है, और मुझे अभी तक (अनएन्क्रिप्टेड) ​​पीईएम को निचली परतों को स्ट्रिंग के रूप में प्रदान करने का कोई तरीका नहीं मिला है (सिवाय इसके कि ओपनएसएसएल/पायथन "एसएसएल" "बफर" रैपर का उपयोग करके, उदाहरण के लिए wrap_bio , लेकिन यह केवल नवीनतम पायथन 3 संस्करणों में उपलब्ध है, पायथन 2 में नहीं)।
• इसलिए यदि यह असंभव भी है, तो हमें न केवल PKCS#12 को PEM में बदलने की आवश्यकता होगी, बल्कि (अनएन्क्रिप्टेड) ​​​​पीईएम डेटा वाली एक अस्थायी फ़ाइल भी बनानी होगी।

ध्यान दें कि आखिरी बिंदु वह है जो मैं इस समय अनिवार्य रूप से कर रहा हूं, लेकिन मुझे यह बिल्कुल पसंद नहीं है। मैं सर्टिफिकेट वाले ओपनएसएसएल को एक साधारण स्ट्रिंग क्यों नहीं प्रदान कर सकता? इसके अलावा, मैं केवल PKCS#12 फ़ाइल नाम और पासवर्ड को निचली परतों में क्यों नहीं भेज सकता?

मैं एक ओपनएसएसएल विशेषज्ञ के रूप में @reaperhulk में टैग करने जा रहा हूं, लेकिन मेरी समझ यह है कि ओपनएसएसएल के लिए क्लाइंट

@ लुकासा इस मुद्दे को गंभीरता से लेने के लिए धन्यवाद। क्षमा करें यदि यह बहुत तकनीकी लगता है, लेकिन अनिवार्य रूप से यह बस यही है:

आप क्लाइंट प्रमाणपत्र के माध्यम से किसी सेवा तक पहुंचना चाहते हैं। लगभग हर जगह आपको यह एक फ़ाइल और एक पासवर्ड के रूप में मिलता है (जहाँ फ़ाइल PKCS#12 एन्कोडेड है)। अधिकांश एपीआई में, जैसे कि जावा मानक पुस्तकालय, आप इसे केवल फ़ाइल नाम और पासवर्ड देते हैं, और इसके साथ किया जाता है।

हालांकि, पायथन में यह नरक के रूप में जटिल है।

इसलिए लगभग कोई भी ऐसा नहीं करता है। इसके बजाय, वे ओपनएसएसएल के माध्यम से अपनी फ़ाइल और पासवर्ड को हाथ से एक पीईएम फ़ाइल में परिवर्तित करते हैं, और उस फ़ाइल का उपयोग करते हैं। यह ऐसे एप्लिकेशन के प्रत्येक उपयोगकर्ता के लिए प्रशासनिक ओवरहेड है। क्योंकि वे केवल (PKCS#12) फ़ाइल और पासवर्ड को नाम नहीं दे सकते।

मुझे लगता है कि requests लाइब्रेरी को इसे कम से कम जावा की तरह सरल बनाना चाहिए।

requests पहले से ही बेवकूफ जटिल एपीआई को सरल बनाने का एक अच्छा काम करता है, और पीकेसीएस # 12 उपयोग मामला एक बेवकूफ जटिल एपीआई का एक और उदाहरण है।

PKCS#12 उपयोग का मामला एक बेवकूफ जटिल API का एक और उदाहरण है।

हाँ, मैं इससे बिल्कुल भी असहमत नहीं हूँ: स्टैक में कहीं भी PKCS#12 समर्थन के लिए किसी प्रकार का समाधान पाकर मुझे पूरी तरह से खुशी होगी।

मैं जो महसूस करने की कोशिश कर रहा हूं वह यह है कि उस काम को करने के लिए कौन सा कोड आवश्यक है, और इसके परिणामस्वरूप इसे कहां रखा जाना चाहिए। मेरा तर्क इस प्रकार है:

1. आम तौर पर, अनुरोध केवल इसकी एपीआई सतह में जुड़ते हैं यदि ऐसा करने में पर्याप्त उपयोगिता है (अर्थात, यदि यह बहुत से लोगों द्वारा उपयोग किया जाता है या कुछ द्वारा बहुत अधिक उपयोग किया जाता है), और यदि हम जो काम कर रहे हैं उसे ठीक करना मुश्किल है या सूक्ष्म किनारे के मामले हैं।
2. आम तौर पर PKCS#12 का समर्थन करना API सतह के अतिरिक्त के रूप में गिना जाएगा, लेकिन अगर यह cert= के सिंटैक्स को बिल्कुल भी नहीं बदलता है (बस उन चीज़ों को चौड़ा करता है जो इसका समर्थन करेंगे) और व्यवहार को वापस नहीं करता है ( यही है, हम मज़बूती से PKCS#12 फ़ाइलों और PEM फ़ाइलों के बीच अंतर बता सकते हैं, या हम तर्क की दोनों श्रृंखलाओं के माध्यम से आसानी से प्रक्रिया कर सकते हैं), मैं कहूंगा कि यह सतह पर पर्याप्त रूप से मामूली परिवर्तन के रूप में गिना जाता है कि यह शायद इसके लायक है .
3. हालाँकि, ऐसी अन्य जगहें हैं जहाँ यह जा सकता है। उदाहरण के लिए, ट्रांसपोर्ट एडेप्टर स्तर पर, या अनुरोध टूलबेल्ट में एक सहायक के रूप में, या कुछ और।

इसका मतलब है कि मैं यह देखना चाहता हूं कि यह कितना सूक्ष्म है, कोड कितना जटिल है, क्या इसके लिए अतिरिक्त निर्भरता की आवश्यकता है, और फिर उस जानकारी का उपयोग करके यह पता करें कि कोड को कहां रखा जाए। उदाहरण के लिए, मेरे पास अभी एक _suspicion_ है कि मानक लाइब्रेरी PKCS#12 को हैंडल नहीं कर सकती है, जिसका अर्थ यह होगा कि _at best_ Requests केवल PKCS#12 का उपयोग करने में सक्षम होंगे, जिसमें [security] अतिरिक्त इंस्टॉल होगा। इससे भी बदतर स्थिति में हो सकता है कि हमारे पास किसी भी ओपनएसएसएल बाइंडिंग में फ़ंक्शन उपलब्ध न हों, इस स्थिति में हमें इसे काम करने के लिए कुछ वास्तविक बोनर्स सामान करना होगा। इसलिए मैं चाहता था कि @reaperhulk का वजन हो: वह संभवतः हमारे लिए इसे तेजी से स्पष्ट करने में सक्षम होगा जितना कि मैं शोध कर सकता हूं।

मैं इस समर्थन को जोड़ा हुआ देखना चाहता हूं: मुझे बस कुछ ऐसे लोगों को लाने की जरूरत है जो जानते हैं कि काम का दायरा क्या है, यहां टिप्पणी करें और मुझे बताएं कि वास्तव में हमें कितने बड़े पहाड़ को स्थानांतरित करने की आवश्यकता है।

PKCS#12 कार्यान्वयन के लिए एक और विवरण: यदि पासवर्ड को बाइट स्ट्रिंग के बजाय unicode ऑब्जेक्ट के रूप में दिया जाता है, तो Python OpenSSL बाइंडिंग के पुराने संस्करण विफल हो जाते हैं। तो इसे इस तरह load_pkcs12() पास करने से पहले इसे परिवर्तित किया जाना चाहिए:

if isinstance(password, unicode):
    password_bytes = password.encode('utf8')
else:
    password_bytes = password
pkcs12 = OpenSSL.crypto.load_pkcs12(pkcs12_data, password_bytes)

एक पूर्ण कनवर्टर इस तरह दिख सकता है, जहां pkcs12_data बाइनरी डेटा के साथ बाइट स्ट्रिंग होने की उम्मीद है, जबकि password बाइट स्ट्रिंग या यूनिकोड स्ट्रिंग हो सकता है:

def pkcs12_to_pem(pkcs12_data, password):
    # Old versions of OpenSSL.crypto.load_pkcs12() fail if the password is a unicode object
    if isinstance(password, unicode):
        password_bytes = password.encode('utf8')
    else:
        password_bytes = password
    p12 = OpenSSL.crypto.load_pkcs12(pkcs12_data, password_bytes)
    p12_cert = p12.get_certificate()
    p12_key = p12.get_privatekey()
    pem_cert = OpenSSL.crypto.dump_certificate(OpenSSL.crypto.FILETYPE_PEM, p12_cert)
    pem_key = OpenSSL.crypto.dump_privatekey(OpenSSL.crypto.FILETYPE_PEM, p12_key)
    pem = pem_cert + pem_key
    return pem

मुझे लगता है कि PKCS#12 चर्चा प्रारंभिक मुद्दे के दायरे से बाहर है, क्योंकि विचाराधीन मुद्दा यह है कि क्या अनुरोधों को मूल रूप से PKCS#12 का समर्थन करना चाहिए। मैं वोट दूंगा कि इसका अपना मुद्दा हो, लेकिन जाहिर है कि यह प्रभारी लोगों पर निर्भर है।

उस ने कहा, एक वर्कअराउंड के रूप में जिसे अनएन्क्रिप्टेड अस्थायी फ़ाइलों की आवश्यकता नहीं है, OpenSSL.crypto.dump_privatekey विधि में एक वैकल्पिक पासफ़्रेज़ पैरामीटर है, इसलिए आप इस तरह से PEM प्रारूप में एन्क्रिप्टेड निजी कुंजी की एक प्रति प्राप्त कर सकते हैं। यह एन्क्रिप्टेड पीईएम समस्या को कम कर देगा जिसे हमने शुरू किया था।

वैकल्पिक रूप से, आप use_privatekey की OpenSSL.SSL.Context पद्धति का उपयोग करने से पहले मेरे द्वारा सुझाए गए के समान हैक भी लिख सकते हैं। मेरे सिर के ऊपर से (अनचाहे) कुछ इस तरह

# From somewhere
pkcs12_data = ...
password_bytes = ...

class Pkcs12Context(requests.packages.urllib3.contrib.pyopenssl.OpenSSL.SSL.Context):
    def __init__(self, method):
        super(PasswordContext, self).__init__(method)
        p12 = OpenSSL.crypto.load_pkcs12(pkcs12_data, password_bytes)
        self.use_certificate(p12.get_certificate())
        self.use_privatekey(p12.get_privatekey())
# Monkey-patch the subclass into OpenSSL.SSL so it is used in place of the stock version
requests.packages.urllib3.contrib.pyopenssl.OpenSSL.SSL.Context = Pkcs12Context

फिर बिना किसी प्रमाणपत्र को निर्दिष्ट किए केवल requests.get आदि का उपयोग करें, क्योंकि यह पहले से ही कन्स्ट्रक्टर में संभाला जा चुका है।

अब इस धागे की समीक्षा कर रहे हैं। मूल का पुनर्लेखन:

एक एन्क्रिप्टेड पीईएम स्वरूपित क्लाइंट प्रमाणपत्र दिया गया है, क्या अनुरोध एक पासवर्ड प्रदान करने के लिए अनुरोध कर सकता है?

चूंकि यह वर्तमान मानक libs में है, इसलिए इस विकल्प को एकीकृत करना बहुत अच्छा होगा। यह उद्यम सुरक्षा विचारों के लिए अत्यंत मूल्यवान होगा (जहां हमारे प्रमाणपत्र एन्क्रिप्ट किए गए हैं, और ऐसा रहने के लिए हैं)।

इस बिंदु पर, यह एक कस्टम ssl संदर्भ को urllib3 में ट्रांसपोर्ट एडॉप्टर का उपयोग करके पास करके किया जा सकता है। यह मानक पुस्तकालय एसएसएल संदर्भ जो कुछ भी अनुमति देता है वह कर सकता है। आप यहां एक कस्टम संदर्भ पारित करने का एक उदाहरण देख सकते हैं।

मैं .pfx और .p12 को एक अस्थायी फ़ाइल का उपयोग करके इसे .pem में परिवर्तित करके अनुरोधों के साथ उपयोग करने में सक्षम था। देखें https://gist.github.com/erikbern/756b1d8df2d1487497d29b90e81f8068

अगर कोई दिलचस्पी है, तो मैं एक पीआर जमा कर सकता हूं। अस्थायी फ़ाइल और संदर्भ प्रबंधक से बचना बहुत अच्छा होगा। मुझे बताओ।

यह विलय होने की संभावना नहीं है, मुझे डर है, लेकिन ध्यान दें कि अब आप एक PyOpenSSL संदर्भ को सीधे ट्रांसपोर्ट एडेप्टर के माध्यम से अनुरोधों को पास कर सकते हैं, ताकि आप पा सकें कि आप उस मुद्दे को दरकिनार कर सकते हैं।

यह विलय होने की संभावना नहीं है, मुझे डर है, लेकिन ध्यान दें कि अब आप एक PyOpenSSL संदर्भ को सीधे ट्रांसपोर्ट एडेप्टर के माध्यम से अनुरोधों को पास कर सकते हैं, ताकि आप पा सकें कि आप उस मुद्दे को दरकिनार कर सकते हैं।

भ्रमित होने के लिए खेद है, लेकिन क्या आप कह रहे हैं कि pfx/p12 समर्थन सामान्य रूप से विलय नहीं होने की संभावना है? (संदर्भ आदि के माध्यम से सही तरीके से किया गया मानते हुए)। इसे एक शॉट देने में खुशी हुई लेकिन जाहिर तौर पर मेरे समय के लायक नहीं है अगर इसे विलय नहीं किया जा रहा है।

मेरा मानना ​​​​है कि "विलय होने की संभावना नहीं है" अस्थायी फ़ाइल समाधान के बारे में था।

@erikbern स्पष्ट होने के लिए, मुझे किसी भी समाधान से संपर्क करने और विलय करने में खुशी हो रही है जो कुछ हद तक लगातार काम करता है। उदाहरण के लिए, urllib3 में PyOpenSSL contrib मॉड्यूल के माध्यम से PKCS#12 का उपयोग करने का समाधान स्वीकार्य होगा।

हालांकि, एक अस्थायी फ़ाइल समाधान स्वीकार्य नहीं है (जैसा कि @vog द्वारा नोट किया गया है)। इसका मतलब है कि PKCS#12 के लिए समर्थन मानक पुस्तकालय के साथ काम करने की संभावना नहीं है, क्योंकि मानक पुस्तकालय ssl मॉड्यूल इसके लिए किसी भी समर्थन का खुलासा नहीं करता है, और इसलिए यह सभी अनुरोध कॉन्फ़िगरेशन में समर्थित नहीं होगा।

बढ़िया है। मैं यह भी मानता हूं कि अस्थायी फ़ाइल खराब है क्योंकि डिस्क पर डिक्रिप्ट की गई कुंजियों को संग्रहीत करने का सुरक्षा जोखिम है। अगले हफ्ते इसे देख सकते हैं। ssl मॉड्यूल के बारे में ध्यान देने के लिए धन्यवाद - यदि सीमा requests से बाहर है तो जाहिर है कि यह मुश्किल हो जाता है

मैंने इसे देखा और ssl मॉड्यूल ने cadata तर्क जोड़ा जहां आप कच्चे स्ट्रिंग के रूप में पेम डेटा पास कर सकते हैं: https://docs.python.org/3/library/ssl.html #ssl.SSLContext.load_verify_locations

हमें यह काम करने के लिए urllib3 को कई स्थानों पर पैच करना होगा, इसलिए मैं वहां से शुरू कर सकता हूं

@erikbern स्पष्ट है कि, इस तरह लगभग किसी भी समाधान बेहतर सिर्फ एक उचित रूप से कॉन्फ़िगर किए बिना पारित करके काम करेंगे SSLContext urllib3 करने के लिए वस्तु एक का उपयोग कर TransportAdapter ।

https://github.com/kennethreitz/requests/issues/2519 इस मुद्दे के समान प्रतीत होता है, इसलिए उन्हें शायद विलय कर दिया जाना चाहिए

इस मुद्दे पर कोई अपडेट मैं एक क्लाइंट प्रमाणपत्र का उपयोग करने का प्रयास कर रहा हूं जो पासवर्ड एन्क्रिप्टेड है और इसे काम करने में असमर्थ है। क्या मुझे अनुरोधों के अलावा अन्य विकल्पों की तलाश करनी चाहिए? क्या आप कृपया ASAP का जवाब दे सकते हैं।

क्या हम इसका दस्तावेजीकरण करते हैं? मुझे लगता है कि यह हमारी सबसे अनुरोधित विशेषता है।

मेरा मानना ​​​​है कि यह धागा 2013 में शुरू हुआ था और मुझे अंत तक समझाया गया कोई संकल्प नहीं मिला। क्या आप लोगों ने पासवर्ड प्रदान करने का विकल्प प्रदान किया था? या यह अभी भी प्रगति पर है?

मैं एक ऐप सुरक्षा उत्पाद में अनुरोधों का उपयोग करने की कोशिश कर रहा हूं जिसे मैं बना रहा हूं। तो कोई भी संकेत सहायक होगा

@AnoopPillai क्या आपने इस टिप्पणी की जाँच की? https://github.com/requests/requests/issues/1573#issuecomment -188125157

हां, मैंने यह टिप्पणी पढ़ी है, यह एक काम है लेकिन मेरे मामले में मैं इसे 2 प्रमाणित फाइलों में परिवर्तित नहीं करना चाहता क्योंकि इसे मेरे आवेदन के बाहर करना होगा। अधिक से अधिक हम एन्क्रिप्टेड .pem फ़ाइल के लिए पासवर्ड संग्रहीत करने के लिए एक तिजोरी जैसी चीज़ का उपयोग करते हैं।

यह पासवर्ड रन टाइम पर ऐप द्वारा गतिशील रूप से पुनर्प्राप्त किया जाता है ताकि कोई हार्ड कोडिंग न हो।

@ अनूपपिल्लई ठीक है।

@kennethreitz नहीं, हमने इसे दस्तावेज नहीं किया।

@ अनूपपिल्लई हाँ, यह ठीक काम करता है। आपको बस कुछ निचले स्तर के हुक का उपयोग करने की आवश्यकता है। इस मामले में, हम आपको ट्रांसपोर्ट एडॉप्टर स्तर पर सीधे urllib3 को SSLContext पास करने की अनुमति देते हैं। यह आपको अंतर्निहित कार्यों तक पहुंच की अनुमति देता है जो आपको पासफ़्रेज़ या पासफ़्रेज़ फ़ंक्शन प्रदान करने की अनुमति देगा। इस प्रकार हम अनुशंसा करते हैं कि आप इसका समर्थन करें।

@AnoopPillai एक अस्थायी फ़ाइल का उपयोग करके समाधान करता है जो मुझे उपयोगी https://gist.github.com/erikbern/756b1d8df2d1487497d29b90e81f8068

मुझे यह बताने के लिए धन्यवाद लुकासा कि ऐसा करने का एक तरीका है।
मैं अजगर के लिए बहुत नया हूं और 3.6 संस्करण का उपयोग कर रहा हूं। क्या आप मेरा मार्गदर्शन कर सकते हैं जहां मुझे क्लाइंट सर्टिफिकेट के पासवर्ड को पास करने के लिए सिफर जैसे विकल्प मिल सकते हैं।
@Erikbern मैं अस्थायी फ़ाइल समाधान से नहीं देखूंगा । जवाब के लिए धन्यवाद।

@ अनूपपिल्लई आपको load_cert_chain ।

@ लुकासा क्या आप इसका दस्तावेजीकरण करेंगे? केवल कुछ मिनट लगने चाहिए (मैं उन्नत अनुभाग में सोच रहा हूं, या शायद एक नए उन्नत उन्नत अनुभाग में)

क्षमा करें दोस्तों, अजगर के साथ मेरे अनुभव की कमी का कारण हो सकता है, लेकिन मैं ऊपर बताए गए कोड लुकासा को संशोधित करने में असमर्थ हूं। मेरा कोड है:

class DESAdapter(HTTPAdapter):
    """
    A TransportAdapter that re-enables 3DES support in Requests.
    """
    def init_poolmanager(self, *args, **kwargs):
        context = create_urllib3_context(load_cert_chain='rtmqa-clientid.pem',password='weblogic')
        kwargs['ssl_context'] = context
        return super(DESAdapter, self).init_poolmanager(*args, **kwargs)

    def proxy_manager_for(self, *args, **kwargs):
        context = create_urllib3_context(load_cert_chain='rtmqa-clientid.pem', password='weblogic')
        kwargs['ssl_context'] = context
        return super(DESAdapter, self).proxy_manager_for(*args, **kwargs)

s = requests.Session()
s.mount(url, DESAdapter())
r = s.get(url, headers=request_header).json()

और मुझे एक त्रुटि मिलती है
लेखन त्रुटि: create_urllib3_context () को एक अनपेक्षित कीवर्ड तर्क 'load_cert_chain' मिला

यह एक गलती है, हाँ। आप create_urllib3_context पर कॉल करना चाहते हैं और उसका रिटर्न वैल्यू प्राप्त करना चाहते हैं, और फिर लौटाई गई वस्तु पर load_cert_chain पर कॉल करना चाहते हैं। इंटरैक्टिव दुभाषिया में उन कार्यों के साथ खेलने की कोशिश करें कि वे कैसे काम करते हैं।

मेरे मैक पर स्थापित urllib3..util.ssl_.py में पासवर्ड के लिए नवीनतम विकल्प नहीं है।
यह कोड है

    if certfile:
        context.load_cert_chain(certfile, keyfile)
    if HAS_SNI:  # Platform-specific: OpenSSL with enabled SNI
        return context.wrap_socket(sock, server_hostname=server_hostname)

पासवर्ड विकल्प गायब है। नवीनतम संस्करण प्राप्त करने के लिए मैं ssl_.py को कैसे अपडेट करूं?

@ अनूपपिल्लई आप नहीं। बिना तर्क के फ़ंक्शन को कॉल करें, फिर लौटाई गई वस्तु पर load_cert_chain पर कॉल करें। आपको urllib3 में परिवर्तन की आवश्यकता नहीं है।

स्पष्ट होने के लिए, इस तरह:

ctx = create_urllib3_context()
ctx.load_cert_chain(your_arguments_here)

आइए इसे दस्तावेज करें :)

@ erikbern मैंने आपके अस्थायी समाधान की कोशिश की लेकिन मुझे निम्नलिखित त्रुटि मिली:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/contrib/pyopenssl.py", line 441, in wrap_socket
    cnx.do_handshake()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/OpenSSL/SSL.py", line 1716, in do_handshake
    self._raise_ssl_error(self._ssl, result)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/OpenSSL/SSL.py", line 1456, in _raise_ssl_error
    _raise_current_error()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/OpenSSL/_util.py", line 54, in exception_from_error_queue
    raise exception_type(errors)
OpenSSL.SSL.Error: [('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/connectionpool.py", line 595, in urlopen
    self._prepare_proxy(conn)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/connectionpool.py", line 816, in _prepare_proxy
    conn.connect()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/connection.py", line 326, in connect
    ssl_context=context)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/util/ssl_.py", line 329, in ssl_wrap_socket
    return context.wrap_socket(sock, server_hostname=server_hostname)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/contrib/pyopenssl.py", line 448, in wrap_socket
    raise ssl.SSLError('bad handshake: %r' % e)
ssl.SSLError: ("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/adapters.py", line 440, in send
    timeout=timeout
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/connectionpool.py", line 639, in urlopen
    _stacktrace=sys.exc_info()[2])
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/util/retry.py", line 388, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='credit-cards-accounts-qa.kdc.capitalone.com', port=443): Max retries exceeded with url: /credit-cards-accounts/credit-cards/accounts/XqLuxBTABbIDvpw56ba34p2WV9JoWUSkPJ09hrBlWD8= (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/tsu892/Desktop/Office/Pythone-work/ASR-pythone/ASR-python3.6/test-request.py", line 48, in <module>
    r = requests.get(url, headers=request_header, cert=cert).json()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/api.py", line 72, in get
    return request('get', url, params=params, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/api.py", line 58, in request
    return session.request(method=method, url=url, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/adapters.py", line 506, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='credit-cards-accounts-qa.kdc.capitalone.com', port=443): Max retries exceeded with url: /credit-cards-accounts/credit-cards/accounts/XqLuxBTABbIDvpw56ba34p2WV9JoWUSkPJ09hrBlWD8= (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),))

नीचे मेरा कोड है:

import requests
import json
import OpenSSL.crypto
import tempfile
import os
import contextlib
import ssl

json_file='apiInput.json'
hdr_key=[]
hdr_value=[]
json_data=open(json_file)
data = json.load(json_data)
request_body={}
#pprint(data)
json_data.close()
request_data = data['request1']
request_header=request_data['header-data']
url=request_header['url']

@contextlib.contextmanager
def pfx_to_pem():
    print('inside pfx tp pem')
    with tempfile.NamedTemporaryFile(suffix='.pem') as t_pem:
        f_pem = open(t_pem.name, 'wb')
        fr_pfx = open('rtmqa-clientid.pfx', 'rb').read()
        p12 = OpenSSL.crypto.load_pkcs12(fr_pfx,'xxxxxxxxx')
        f_pem.write(OpenSSL.crypto.dump_privatekey(OpenSSL.crypto.FILETYPE_PEM, p12.get_privatekey()))
        f_pem.write(OpenSSL.crypto.dump_certificate(OpenSSL.crypto.FILETYPE_PEM, p12.get_certificate()))
        ca = p12.get_ca_certificates()
        if ca is not None:
            for cert in ca:
                f_pem.write(OpenSSL.crypto.dump_certificate(OpenSSL.crypto.FILETYPE_PEM, cert))
        f_pem.close()
        yield t_pem.name

with pfx_to_pem() as cert:
    print(cert)
    r = requests.get(url, headers=request_header, cert=cert).json()
print(r.status_code)
print(r.json())

क्षमा करें, यह जानना कठिन है कि यह आपकी टिप्पणी से क्यों टूट रहा है। मैंने इसे अनुप्रयोगों के समूह के लिए उपयोग किया है और इसमें कोई समस्या नहीं है

@ लुकासा मैंने उस कोड परिवर्तन (नीचे चिपकाया गया कोड) के साथ प्रयास किया और उसी त्रुटि के साथ समाप्त हुआ जो मुझे tempfile विधि के साथ मिला।

import requests
import json
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util.ssl_ import create_urllib3_context

json_file='apiInput.json'
hdr_key=[]
hdr_value=[]
json_data=open(json_file)
data = json.load(json_data)
request_body={}
#pprint(data)
json_data.close()
request_data = data['request1']
request_header=request_data['header-data']
url=request_header['url']

class DESAdapter(HTTPAdapter):
    """
    A TransportAdapter that re-enables 3DES support in Requests.
    """
    def init_poolmanager(self, *args, **kwargs):
        context = create_urllib3_context()
        context.load_cert_chain('rtmqa-clientid.pem',password='weblogic')
        kwargs['ssl_context'] = context
        return super(DESAdapter, self).init_poolmanager(*args, **kwargs)

    def proxy_manager_for(self, *args, **kwargs):
        context = create_urllib3_context()
        context.load_cert_chain('rtmqa-clientid.pem',password='weblogic')
        kwargs['ssl_context'] = context
        return super(DESAdapter, self).proxy_manager_for(*args, **kwargs)

s = requests.Session()
s.headers=request_header
s.mount(url, DESAdapter())
r = s.get(url)

/Users/tsu892/Python3.6/bin/python /Users/tsu892/Desktop/Office/Pythone-work/ASR-pythone/ASR-python3.6/Test-ASRreq.py
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/contrib/pyopenssl.py", line 441, in wrap_socket
    cnx.do_handshake()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/OpenSSL/SSL.py", line 1716, in do_handshake
    self._raise_ssl_error(self._ssl, result)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/OpenSSL/SSL.py", line 1456, in _raise_ssl_error
    _raise_current_error()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/OpenSSL/_util.py", line 54, in exception_from_error_queue
    raise exception_type(errors)
OpenSSL.SSL.Error: [('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/connectionpool.py", line 595, in urlopen
    self._prepare_proxy(conn)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/connectionpool.py", line 816, in _prepare_proxy
    conn.connect()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/connection.py", line 326, in connect
    ssl_context=context)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/util/ssl_.py", line 329, in ssl_wrap_socket
    return context.wrap_socket(sock, server_hostname=server_hostname)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/contrib/pyopenssl.py", line 448, in wrap_socket
    raise ssl.SSLError('bad handshake: %r' % e)
ssl.SSLError: ("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/adapters.py", line 440, in send
    timeout=timeout
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/connectionpool.py", line 639, in urlopen
    _stacktrace=sys.exc_info()[2])
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/urllib3/util/retry.py", line 388, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='credit-cards-accounts-qa.kdc.capitalone.com', port=443): Max retries exceeded with url: /credit-cards-accounts/credit-cards/accounts/XqLuxBTABbIDvpw56ba34p2WV9JoWUSkPJ09hrBlWD8= (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/tsu892/Desktop/Office/Pythone-work/ASR-pythone/ASR-python3.6/Test-ASRreq.py", line 37, in <module>
    r = s.get(url)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/sessions.py", line 521, in get
    return self.request('GET', url, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/requests/adapters.py", line 506, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='credit-cards-accounts-qa.kdc.capitalone.com', port=443): Max retries exceeded with url: /credit-cards-accounts/credit-cards/accounts/XqLuxBTABbIDvpw56ba34p2WV9JoWUSkPJ09hrBlWD8= (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),))

@erikbern यह मेरे लैपटॉप पर एक सेटअप समस्या हो सकती है। मैं एक मैक का उपयोग करता हूं, पाइथोन 3.6

6c40089ea258:~ tsu892$ pip3 show requests
Name: requests
Version: 2.18.4
Summary: Python HTTP for Humans.
Home-page: http://python-requests.org
Author: Kenneth Reitz
Author-email: [email protected]
License: Apache 2.0
Location: /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages
Requires: idna, certifi, chardet, urllib3

6c40089ea258:~ tsu892$ pip3 show certifi
Name: certifi
Version: 2017.7.27.1
Summary: Python package for providing Mozilla's CA Bundle.
Home-page: http://certifi.io/
Author: Kenneth Reitz
Author-email: [email protected]
License: MPL-2.0
Location: /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages
Requires: 

क्या आपको लगता है कि प्रमाणपत्र में कुछ गड़बड़ है?

python -m requests.help का आउटपुट क्या है?

@ लुकासा आउटपुट है:

6c40089ea258:~ tsu892$ python3 -m requests.help?
/Library/Frameworks/Python.framework/Versions/3.6/bin/python3: No module named requests.help?

कृपया अपनी कमांड लाइन से प्रश्न चिह्न हटा दें।

6c40089ea258:~ tsu892$ python3 -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.0.3"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.2"
  },
  "platform": {
    "release": "16.7.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "1010006f",
    "version": "17.2.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020bf"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}

तो आपको जो त्रुटि मिल रही है वह हमारे सर्वर टीएलएस प्रमाणपत्र को सत्यापित करने में असमर्थ होने के कारण है। सर्टिफिकेट और ओपनएसएसएल सही लगते हैं, इसलिए मुझे लगता है कि सर्वर गलत व्यवहार कर रहा है। आप किस सर्वर तक पहुंचने की कोशिश कर रहे हैं?

एप्लिकेशन को क्लाउड एडब्ल्यूएस पर तैनात किया गया है। लेकिन जब हम एपीआई को कॉल करते हैं तो यह पहले ओएसबी में जाता है जो प्रमाण पत्र को प्रमाणित करता है और फिर अनुरोध को एडब्ल्यूएस को रूट करता है।
मैं एक ही प्रमाणपत्र का उपयोग करता हूं और डाकिया या मेरे रूबी कोड का उपयोग करके एपीआई ठीक काम करता है

क्या आपको एक विशिष्ट रूट प्रमाणपत्र की आवश्यकता है? क्या आप मेरे लिए पहुँचा जा रहा होस्ट नाम प्रदान कर सकते हैं?

पथ के बिना होस्ट URL https://credit-cards-accounts-qa.kdc.capitalone.com है
यह एक आंतरिक समापन बिंदु है

हाँ, इसलिए मैं नहीं देख सकता कि वहाँ क्या हो रहा है। क्या आप openssl s_client -showcerts -connect credit-cards-accounts-qa.kdc.capitalone.com:443 चला सकते हैं और पूरा आउटपुट प्रदान कर सकते हैं?

हटाए गए

ऐसा लगता है कि आप विश्व स्तर पर विश्वसनीय रूट प्रमाणपत्र का उपयोग नहीं कर रहे हैं। उस सेवा के लिए मूल प्रमाणपत्र कहाँ है?

मैं किसी अन्य प्रमाणपत्र का उपयोग नहीं कर रहा हूं। सुनिश्चित नहीं है कि अगर दृश्य के पीछे कोई रूट प्रमाणपत्र उपयोग किया जाता है तो क्या मेरे लिए यह पता लगाने का कोई तरीका है?

हाँ, Chrome के डेवलपर टूल आपको उसके द्वारा उपयोग की जा रही पूर्ण प्रमाणपत्र श्रृंखला के बारे में बताएंगे।

आप शायद किसी को देखने के लिए कुछ आंतरिक प्रमाणपत्र ऑनलाइन पोस्ट नहीं करना चाहते हैं ...

@erikbern यह सार्वजनिक सूचना है। आप समान आदेश चलाकर समान परिणाम प्राप्त कर सकते हैं।

@SethMichaelLarson @erikbern के GitHub प्रोफाइल "चीफ ट्रोल ऑफिसर" से। शायद वे सिर्फ ट्रोलिंग कर रहे थे?

@erikbern @sigmavirus24 आह! मुझे नहीं पता था कि मैं किससे बात कर रहा हूं। आगे बढ़ना! मैं

जब मैं डाकिया से दौड़ता हूं तो मुझे sha-1 प्रमाणपत्र के अलावा कुछ भी दिखाई नहीं देता
हो सकता है कि मुझे इसे किसी भी तरह से Pycharm में जोड़ने की आवश्यकता हो

यदि आप सचमुच क्रोम में वेबसाइट पर ब्राउज़ करते हैं जो पर्याप्त होना चाहिए।

@SethMichaelLarson किस कमांड को चला रहा है? FYI करें अब टिप्पणी हटा दी गई है लेकिन पहले यहां एक संपूर्ण BEGIN CERTIFICATE ब्लॉब था ... afaik आप इसे ऑनलाइन साझा नहीं करना चाहते हैं

@erikbern वह

प्रमाणपत्र सार्वजनिक डेटा हैं; वे प्रत्येक कनेक्शन प्रयास पर नेटवर्क पर सादे पाठ में प्रेषित होते हैं।

मैं प्रमाणित श्रृंखला में गया और केवल एक Sha-1 प्रमाणपत्र और .Pem प्रमाणपत्र मिला जिसका उपयोग मैं API को हिट करने के लिए कर रहा हूं

@AnoopPillai मुझे आपका उदाहरण कोड 1 सितंबर से पासवर्ड के साथ क्लाइंट-साइड पेम फ़ाइल का उपयोग किए बिना समस्या के बिना काम कर रहा है। ऐसा लगता है कि होस्ट नियमित प्रमाणपत्र का उपयोग कर रहा है। @ लुकासा के साथ बहुत बहुत धन्यवाद!

मुझे दुर्भाग्य से अभी भी समस्याएं आ रही हैं, यहां तक ​​​​कि Temp फ़ाइल विधि के साथ भी। मैं Google पोस्टमैन में .pfx का उपयोग कर सकता हूं और मुझे प्रमाणित करने में कोई समस्या नहीं है (इसलिए मुझे अपने क्रेडेंशियल काम पता है), लेकिन मुझे अभी भी पायथन के साथ 401 मिल रहे हैं। दुर्भाग्य से जिस कंपनी के साथ मैं काम कर रहा हूं उसका समर्थन करने वाला व्यक्ति बहुत मदद नहीं कर रहा है - क्या किसी के पास समस्या निवारण के लिए कोई सुझाव है?

इस स्तर पर मैं वास्तव में अनिश्चित हूं कि समस्या को कहां देखना है क्योंकि अन्य लोग Temp फ़ाइल विधि के साथ सफलता की रिपोर्ट कर रहे हैं और मैंने अभी भी उनकी सर्टिफिकेट प्रबंधन टीम से कुछ भी नहीं सुना है।

किसी भी सलाह की बहुत सराहना की जाएगी - कृपया मुझे बताएं कि क्या मैं इसे आसान बनाने के लिए कोई अतिरिक्त जानकारी प्रदान कर सकता हूं।

धन्यवाद :)

बस एक सुझाव, क्या आपने PFX को PEM में बदलने की कोशिश की? साथ ही, यदि सर्वर उपयोगकर्ता नाम/पासवर्ड का भी उपयोग कर रहा है, तो आपको auth=() का उपयोग करके प्राप्त/पोस्ट अनुरोध जोड़ने की आवश्यकता होगी। मैं पासवर्ड से सुरक्षित PEM फ़ाइल का उपयोग करके, बिना किसी समस्या के अब कई हफ्तों से उपरोक्त class DESAdapter(HTTPAdapter) दृष्टिकोण का उपयोग कर रहा हूं।

@ideasean अभी भी अमान्य क्रेडेंशियल प्राप्त कर रहा है। मुझे temp फ़ाइल विधि के लिए लिखे गए pfx_to_pem फ़ंक्शन द्वारा जेनरेट की गई .pem फ़ाइल पर load_cert_chain को इंगित करना चाहिए, है ना? इसमें निजी कुंजी और प्रमाणपत्र है।

चूंकि .pfx पोस्टमैन के साथ काम करता है लेकिन यह यहां प्रमाणित नहीं होगा, क्या इसका मतलब यह हो सकता है कि रूपांतरण प्रक्रिया में कुछ गलत हो रहा है?

मैंने अस्थायी फ़ाइल विधि का उपयोग नहीं किया। मैंने DESAdapter दृष्टिकोण का बहुत अधिक उपयोग किया जैसा कि अनूपपिल्लई की पोस्ट में सितंबर 1 को ऊपर से शुरू में लिखा गया है -

मैंने उस कोड परिवर्तन (नीचे चिपकाया गया कोड) के साथ प्रयास किया और उसी त्रुटि के साथ समाप्त हुआ जो मुझे tempfile विधि के साथ मिला।

मैं रूपांतरण प्रक्रिया से बात नहीं कर सकता, लेकिन शायद एक अच्छा परीक्षण पोस्टमैन के साथ परिवर्तित पेम फ़ाइल का उपयोग करने का प्रयास करना है?

यह भी ध्यान दें कि मैंने उपरोक्त दृष्टिकोण का उपयोग किया क्योंकि मेरी पेम फ़ाइल एन्क्रिप्टेड/पासवर्ड संरक्षित थी, और पाइथन अनुरोध वर्तमान में इसका समर्थन नहीं करते हैं। यदि आपका पीईएम पासवर्ड से सुरक्षित नहीं है, तो आप प्रति लिंक मूल अनुरोधों का उपयोग करने में सक्षम होना चाहिए (लेकिन तब आपके फाइल सिस्टम पर एक असुरक्षित प्रमाणपत्र होगा)।

@ideasean मैंने इस विधि के अनुसार .pfx को तोड़ा और बैग विशेषताओं और प्रमाणपत्र के साथ एक .pem फ़ाइल के साथ-साथ बैग विशेषताओं और एक एन्क्रिप्टेड निजी कुंजी के साथ एक .pem फ़ाइल प्राप्त की।

अभी भी अमान्य प्रमाण-पत्र प्राप्त कर रहे हैं, मुझे लगता है कि मैं पोस्टमैन के माध्यम से कर्ट डालने का प्रयास करूंगा और देख सकता हूं कि वे काम करते हैं या नहीं, लेकिन मैं यह नहीं समझ सकता कि मैं इस .pfx को ठीक से अनपैक करने में असमर्थ क्यों हूं

मैंने ओपनएसएल कमांड openssl pkcs12 -in <my_pfx>.pfx -out certificate.cer -nodes की भी कोशिश की, और यह अभी भी मुझे 401 त्रुटि दे रहा है जब मैं इसे इस तरह बदलता हूं: context.load_cert_chain('certificate.cer')

मैंने उपर्युक्त .cer स्थापित किया है और जब मैं एपीआई कॉल करता हूं तो पोस्टमैन इसका उपयोग करने के लिए भी नहीं कहता है (पॉपअप के विपरीत जब यह .pfx का उपयोग करने के लिए कहता है), यह सुनिश्चित नहीं है कि मैं इसे उस विशिष्ट प्रमाण का उपयोग कैसे कर सकता हूं चूंकि सेटिंग्स में कोई "प्रमाणपत्र" पैनल नहीं है जैसे दस्तावेज़ कहते हैं कि वहां है।

आप पोस्टमैन के ब्राउज़र संस्करण का उपयोग कर रहे होंगे, जिसमें प्रमाणपत्र पैनल, एसएसएल सत्यापन अक्षम आदि शामिल नहीं है। प्रमाणपत्र सेटिंग बदलने के लिए पूर्ण क्लाइंट का प्रयास करें। हो सकता है कि आप इस चर्चा को किसी अन्य विषय पर जारी रखना चाहें, क्योंकि हम विषय से थोड़ा हटकर हैं।

@ mkane848 ने आपकी मूल टिप्पणी देखी जहां आपको ValueError: String expected । आप https://github.com/pyca/pyopenssl/issues/701 और https://github.com/shazow/urllib3/issues/1275 की जांच कर सकते हैं

मैं इसका उपयोग कर पासवर्ड के साथ अपने निजी पेम का उपयोग करता हूं:

from requests.adapters import HTTPAdapter

from urllib3.util.ssl_ import create_urllib3_context

class SSLAdapter(HTTPAdapter):
    def __init__(self, certfile, keyfile, password=None, *args, **kwargs):
        self._certfile = certfile
        self._keyfile = keyfile
        self._password = password
        return super(self.__class__, self).__init__(*args, **kwargs)

    def init_poolmanager(self, *args, **kwargs):
        self._add_ssl_context(kwargs)
        return super(self.__class__, self).init_poolmanager(*args, **kwargs)

    def proxy_manager_for(self, *args, **kwargs):
        self._add_ssl_context(kwargs)
        return super(self.__class__, self).proxy_manager_for(*args, **kwargs)

    def _add_ssl_context(self, kwargs):
        context = create_urllib3_context()
        context.load_cert_chain(certfile=self._certfile,
                                keyfile=self._keyfile,
                                password=str(self._password))
        kwargs['ssl_context'] = context

आपकी जानकारी के लिए, मैंने अभी एक अलग पुस्तकालय के रूप में requests लिए PKCS#12 समर्थन लागू किया है:

• https://pypi.python.org/pypi/requests-pkcs12

कोड एक स्वच्छ कार्यान्वयन है : यह न तो बंदर पैचिंग और न ही अस्थायी फ़ाइलों का उपयोग करता है। इसके बजाय, एक कस्टम TransportAdapter का उपयोग किया जाता है, जो एक कस्टम SSLContext प्रदान करता है।

किसी भी प्रतिक्रिया और सुधार का स्वागत है!

बेशक, मैं चाहता हूं कि requests यह कार्यक्षमता सीधे प्रदान करे, लेकिन जब तक हम वहां नहीं हैं, यह पुस्तकालय दर्द को कम करेगा।

यह बहुत अच्छा होगा यदि हम इसे सरलता से कर सकें:

~~~
cert=("cert.pem", "key.pem", "somepassphrase") # अलग सर्टिफिकेट/कुंजी

cert=("keycert.pem", None, "somepassphrase")    # combined cert/key

~~~

... भले ही यह केवल अजगर 3.3+ पर काम करता हो। यह एपीआई सतह के लिए केवल एक मामूली जोड़ होगा।

AFAICS, इसका मतलब urllib3 में एक छोटा सा बदलाव होगा ताकि HTTPSConnection एक वैकल्पिक password तर्क स्वीकार करे; इसे ssl_wrap_socket माध्यम से पारित किया जाता है, जिसके साथ समाप्त होता है:

~अगर सर्टिफिकेट:यदि पासवर्ड कोई नहीं है:संदर्भ.लोड_सर्ट_चेन (सर्टिफिकेट, कीफाइल, पासवर्ड)अन्यथा:संदर्भ.लोड_सर्ट_चेन (सर्टिफिकेट, कीफाइल)~

तब यह पीछे की ओर-संगत होगा, केवल एक अपवाद उठाना यदि आप किसी पुराने प्लेटफ़ॉर्म पर निजी कुंजी पासफ़्रेज़ का उपयोग करने का प्रयास करते हैं जो इसका समर्थन नहीं करता है।

ध्यान दें कि contrib/pyopenssl.py एडेप्टर पहले से ही इस अतिरिक्त तर्क का load_cert_chain , और ऐसा ही अजगर 2.7 करता है।

इसके अलावा: मैं "गुप्त" डेटा को प्रबंधित करने के लिए एडब्ल्यूएस केएमएस का उपयोग कर रहा हूं, इसलिए मैं केएमएस से रनटाइम पर कुंजी पासवर्ड लोड करूंगा, न कि इसे एप्लिकेशन में हार्ड-कोड।

मैं व्यक्तिगत रूप से इस बदलाव के खिलाफ नहीं रहूंगा, क्योंकि मुझे लगता है कि यह बोर्ड भर में कई उपयोगकर्ताओं के लिए हमारे यूजर इंटरफेस में काफी सुधार करेगा।

@sigmavirus24 कोई विचार?

@candlerb @kennethreitz क्या PKCS#12 मामले को उस API में भी शामिल करना स्वीकार्य होगा?

cert=('keycert.p12', None, 'somepassphrase')

अंतर फ़ाइल एक्सटेंशन ( *.p12 बनाम *.pem ) द्वारा या उस फ़ाइल के पहले बाइट्स को देखकर हो सकता है।

मुझे pkcs#12 लेने के अनुरोधों को अनुमति देने में कोई समस्या नहीं है, जब तक कि इसे सुरक्षित रूप से किया जा सकता है - और मेरी राय में जो निकाली गई निजी कुंजी को अस्थायी फ़ाइल में लिखने से रोकता है।

पायथन पीकेसीएस # 12 के लिए गुगलिंग, मुझे लगता है:

• किसी का कोड जो निजी कुंजी लिखता है
• कुछ अन्य कोड जो मुझे लगता है कि pkcs#12 में पढ़ने के लिए pyOpenSSL पर निर्भर करता है। यह प्रमाणपत्र और कुंजी को डेटा आइटम के रूप में लौटाता है।

तो ऐसा करते हुए, मुझे लगता है कि चीजों को इस तरह से जोड़ना जरूरी होगा कि कुंजी/प्रमाण स्वयं ओपनएसएसएल को पास कर दिया जाए, न कि उन चीजों वाले फ़ाइल नाम। यह बहुत बड़ा बदलाव लगता है।

यदि यह बहुत कठिन है, तो इसका सीधा सा मतलब है कि उपयोगकर्ता को pkcs#12 को PEM ऑफ-लाइन में बदलना होगा, जो कि बहुत सीधा है (और इसे प्रलेखित किया जा सकता है)।

@candlerb जैसा कि मैंने अपनी पिछली टिप्पणी में लिखा था (https://github.com/requests/requests/issues/1573#issuecomment-348968658), मैंने पहले से ही एक स्वच्छ कार्यान्वयन बनाया है जो requests साथ अच्छी तरह से एकीकृत है।

तो आप जिन समस्याओं का वर्णन कर रहे हैं वे पहले ही हल हो चुकी हैं।

जितना संभव हो उतना दूर रहने के लिए अभी मेरा कार्यान्वयन नए pkcs12_* कीवर्ड तर्क जोड़ता है।

लेकिन मुझे लगता है कि इसे इसके बजाय cert कीवर्ड तर्क में एकीकृत किया जाना चाहिए, और मेरा प्रश्न है:

• क्या यह सामान्य रूप से स्वीकार्य होगा?
• क्या मेरा ठोस प्रस्ताव cert=('keycert.p12', None, 'somepassphrase') स्वीकार्य होगा?
• हमें PKCS#12 और PEM में कैसे अंतर करना चाहिए? (फ़ाइल नाम प्रत्यय, या फ़ाइल सामग्री द्वारा?)

(इसके अलावा, मैं इसे अपनी अलग requests_pkcs12 लाइब्रेरी के बजाय requests में देखना पसंद करूंगा। लेकिन इस मुद्दे की उम्र को देखते हुए, मुझे बहुत कम उम्मीद है कि यह जल्द ही ऊपर की ओर जाएगा। हालांकि , अगर इस बारे में कोई ठोस बयान था कि वास्तव में किस प्रकार का कार्यान्वयन चाहिए, तो शायद मैं अपने कार्यान्वयन को तदनुसार समायोजित कर सकता हूं और पुल अनुरोध का प्रस्ताव कर सकता हूं।)

तो, कुछ बातें:

1. मुझे नहीं लगता कि हमें प्रमाणित कीवर्ड लेना चाहिए और इसे इस तरह विस्तारित करना चाहिए। यह परोक्ष रूप से संरचित डेटा है और लोग पहले से ही files कीवर्ड में tuples द्वारा भ्रमित हैं। मुझे लगता है कि एक ज्ञात-बुरे पैटर्न को जारी रखना मूर्खतापूर्ण है।

2. मुझे लगता है कि अगर कुछ भी, pkcs12 एडेप्टर को संशोधित किया जाना चाहिए और अनुरोध-टूलबेल्ट में अपस्ट्रीम किया जाना चाहिए। मुझे लगता है कि उस वस्तु पर स्मृति में pkcs12 पासवर्ड संग्रहीत करने के बजाय ssl_context बनाने के लिए इसे संशोधित करना बेहतर होगा।

मुझे लगता है कि अभी भी अन्य काम हैं जिन्हें करने की आवश्यकता है इससे पहले कि हम इसे और अधिक सामान्य मामले में संभाल सकें, इससे कोई फर्क नहीं पड़ता कि इसमें अनुरोध 3.0 के लिए इसके लिए सही एपीआई निर्धारित करना शामिल है।

@sigmavirus24 प्रतिक्रिया के लिए धन्यवाद।

1. ठीक है, तो चलिए अलग pkcs12_* कीवर्ड रखते हैं।
2. हां, यह निश्चित रूप से सुधार के लायक है। मैंने उसके लिए एक समस्या ट्रैकर प्रविष्टि बनाई: https://github.com/m-click/requests_pkcs12/issues/2

PKCS#12 TransportAdapter वर्ग को requests कैसे शामिल किया जाएगा? क्या उस वर्ग को केवल requests जोड़ा जाएगा, या इसे "गहरे" स्तर पर शामिल करने का कोई और तरीका है, इसलिए इसका उपयोग बिना किसी request()/get()/... रैपर के और स्पष्ट रूप से लोड किए बिना किया जा सकता है अनुकूलक?

मेरे संगठन को PKCS12 प्रमाणपत्रों का उपयोग करने की आवश्यकता है और ऐसा करने के लिए वह आपके पुस्तकालय में आवश्यक सुधार करने के लिए तैयार है। .p12 फ़ाइलों को .pem फ़ाइलों में डिक्रिप्ट करना बहुत अधिक जोखिम वाला माना जाता है और इससे निपटने के लिए एक अतिरिक्त कदम जोड़ा जाता है। हम किसी दिए गए सत्र के लिए उपयुक्त ssl_context उत्पन्न करने और प्रदान करने के लिए कार्यक्षमता जोड़ना चाहते हैं। क्या यह अभी भी कार्यक्षमता है कि आपकी टीम यह मानने को तैयार होगी कि इसे ठीक से लागू किया गया है?

बस एक त्वरित अनुस्मारक: हमारी कंपनी द्वारा पहले से ही एक स्वच्छ कार्यान्वयन प्रदान किया गया है, लेकिन एक अलग एडेप्टर के रूप में: https://github.com/m-click/requests_pkcs12

अनुरोधों के लिए पुल अनुरोध में इसे पुन: स्वरूपित करने के लिए स्वतंत्र महसूस करें।

रास्ते में, आप एक छोटी सी समस्या को ठीक करना चाह सकते हैं: ssl_context को पूरे सत्र के लिए स्मृति में नहीं रखा जाना चाहिए, लेकिन जितनी जल्दी हो सके, केवल एक दिए गए कनेक्शन के लिए। यह सभी देखें:

• https://github.com/m-click/requests_pkcs12/issues/2

यदि आप इसे रास्ते में ठीक करते हैं, तो यह अच्छा होगा यदि आप इसे स्वयं अनुरोधों के अलावा https://github.com/m-click/requests_pkcs12 पर एक छोटे से पुल अनुरोध के रूप में प्रदान कर सकते हैं।

इस तरह, वे सभी लोग जो अभी requests_pkcs12 लाइब्रेरी का उपयोग कर रहे हैं, स्वचालित रूप से उस सुधार से लाभान्वित होंगे, बिना अनुरोधों के लिए (तब बेहतर) नए एपीआई पर स्विच किए बिना।

हाँ, https://github.com/m-click/requests_pkcs12 ने मेरे लिए काम किया और ठीक वही किया जो मैं चाहता था। बहुत बहुत धन्यवाद @वोग ! मुझे आशा है कि अनुरोध अंततः इसका समर्थन करने में सक्षम हैं।

मैं उनके कार्यान्वयन के लिए @vog को भी धन्यवाद मुताबिक काम करता है, और मेरे मामले में S3 जैसे गैर-सुरक्षित स्टोरेज में requests तक अपना रास्ता बना सकता है।