एक सहकर्मीले तपाईंलाई संस्थाको CA प्रमाणपत्र दिन्छ। Requests मा cert नामको प्यारामिटर छ। नामहरू मिल्दा देखिन्छन्, तर तिनीहरू फरक प्रश्नको उत्तर दिन्छन्।

सेटिङउद्देश्य
verifyअर्को पक्ष प्रमाणित गर्न प्रयोग हुने विश्वास सामग्री छान्छ
certक्लाइन्ट प्रमाणीकरण आवश्यक हुँदा क्लाइन्ट प्रमाणपत्र र त्यसको निजी कुञ्जी प्रस्तुत गर्छ

स्वीकृत इन्टरसेप्सन CA का लागि, Requests अपरेशनले इच्छित CA बन्डल छान्न सक्छ:

response = requests.get(
    'https://example.com/',
    proxies=routes,
    verify='/path/to/approved-ca-bundle.pem',
    timeout=15,
)

यहाँ routes अनुप्रयोगको विद्यमान प्रोक्सी म्यापिङ हो। मार्गले यो क्लाइन्टका लागि सही पढ्न योग्य विश्वास बन्डल नाम दिनुपर्छ। यो केवल जडान असफल भयो भनेर छानिएको डाउनलोड गरिएको वेबसाइट प्रमाणपत्र होइन।

वातावरण चर REQUESTS_CA_BUNDLE अर्को समर्थित विश्वास इनपुट हो। अप्रभावी देखिएमा वास्तविक पठाउने मार्ग जाँच्नुहोस्; तयार अनुरोधका कार्यप्रवाहहरू र स्पष्ट सेटिङहरूले वातावरण कन्फिगरेसन कसरी मिलाइन्छ परिवर्तन गर्न सक्छन्।

तपाईंलाई CA को निजी कुञ्जी आवश्यक पर्नु हुँदैन

क्लाइन्टलाई स्वीकृत जारीकर्ता चिन्न आवश्यक पर्ने सार्वजनिक CA प्रमाणपत्र हो। यसको हस्ताक्षर निजी कुञ्जी अर्को पक्षको शक्तिशाली गोप्य कुरा हो। नियमित प्रोक्सी-विश्वास मर्मतको भागका रूपमा यो अनुप्रयोग प्रयोगकर्ताहरूलाई वितरण गर्नु हुँदैन।

क्लाइन्ट प्रमाणपत्र अझै पनि कुनै विशेष गन्तव्य वा अलग कन्फिगर गरिएको TLS सम्बन्धले माग्न सक्छ। त्यो छुट्टै आवश्यकता हो, प्रत्येक प्रमाणपत्र-प्रमाणीकरण त्रुटिबाट अनुमान गरिने कुरा होइन।

अर्को त्रुटि देखा पर्दा अपरेशनको नाम भन्नुहोस्: CA फाइल लोड गर्ने, अर्को पक्षको प्रमाणपत्र प्रमाणित गर्ने, वा क्लाइन्ट पहिचान प्रस्तुत गर्ने। सन्देश नबदलुन्जेल verify र cert बीच फाइल सार्नु यसको भूमिका छान्ने विश्वसनीय तरिका होइन।

सम्बन्धित लेखहरू