Python Requests: CA ബണ്ടിലുകൾ verify-യിൽ ആണ്, cert-യിൽ അല്ല

ഒരു സഹപ്രവർത്തകൻ സംഘടനയുടെ CA സർട്ടിഫിക്കറ്റ് നൽകുന്നു. Requests 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 നും ഇടയിൽ ഫയൽ നീക്കുന്നത് അതിന്റെ പങ്ക് തിരഞ്ഞെടുക്കാനുള്ള വിശ്വസനീയമായ മാർഗമല്ല.