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 အကြား ရွှေ့ခြင်းသည် ၎င်း၏ အခန်းကဏ္ဍကို ရွေးချယ်ရန် ယုံကြည်စိတ်ချရသော နည်းလမ်း မဟုတ်ပါ။