Python Requests: កញ្ចប់ CA គួរនៅក្នុង verify មិនមែន cert ទេ

ដាក់សម្ភារៈទុកចិត្ត CA ដែលបានអនុម័តក្នុងការកំណត់ការផ្ទៀងផ្ទាត់ ជំនួសឱ្យការចាត់ទុកកំហុសវិញ្ញាបនបត្រជាសំណើសម្រាប់កូនសោឯកជនរបស់អតិថិជន។

សហការីម្នាក់ផ្តល់វិញ្ញាបនបត្រ 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 រហូតដល់សារផ្លាស់ប្តូរ មិនមែនជាវិធីដែលអាចទុកចិត្តបានដើម្បីជ្រើសរើសតួនាទីរបស់វាទេ។

អត្ថបទពាក់ព័ន្ធ