Python Requests: د CA بنډلونه په verify کې ځای لري، نه په cert کې
تصویب شوي CA باور توکي په verification ترتیباتو کې ځای په ځای کړئ، پرځای د دې چې د certificate تېروتنه د client شخصي کی غوښتنه وګڼئ.
یو همکار تاسو ته د سازمان CA تصدیق ورکوي. Requests د cert په نوم یو پیرامیټر وړاندې کوي. نومونه سره سمون لري، خو دوی مختلفو پوښتنو ته ځواب وایي.
| ترتیبات | هدف |
|---|---|
verify | هغه باور توکي غوره کوي چې د مقابل لوري د تصدیق لپاره کارېږي |
cert | کله چې د client تصدیق ته اړتیا وي، د client تصدیق لیک او د هغې شخصي کی وړاندې کوي |
د تصویب شوي مداخلې CA لپاره، یو Requests عملیات کولای شي نظر ترلاسه شوی CA بنډل غوره کړي:
response = requests.get(
'https://example.com/',
proxies=routes,
verify='/path/to/approved-ca-bundle.pem',
timeout=15,
)دلته routes د اپلیکیشن اوسنى پروکسي نقشه ده. لاره باید دې client لپاره سم لوستل کیدونکی باور بنډل ونوموي. دا د ویب پاڼې هغه تصدیق نه دی چې یوازې د دې لپاره غوره شوی چې اړیکه ناکامه شوه.
د محیط متغیر REQUESTS_CA_BUNDLE یو بل ملاتړ شوی باور داخل دی. که دا بې اغیزه ښکاره شي، اصلي لېږدونکې لاره وګورئ؛ د چمتو شویو غوښتنو کاري جریانونه او څرګند ترتیبات کولای شي بدل کړي چې د محیط ترتیبات څنګه یوځای کیږي.
تاسو باید د CA شخصي کی ته اړتیا ونلرئ
عامه CA تصدیق هغه څه دي چې client یې د تصویب شوي صادرونکي پېژندلو لپاره اړتیا لري. د هغې لاسلیک شخصي کی د بل لوري پیاوړی راز دی. دا باید د معمول پروکسي-باور ترمیم برخې په توګه د اپلیکیشن کاروونکو ته ونه ویشل شي.
د client تصدیق ممکن لا هم د یو ځانګړي منزل یا بل جلا تنظیم شوي TLS اړیکې لخوا وغوښتل شي. دا جلا اړتیا ده، نه هغه څه چې له هر certificate تصدیق تېروتنې څخه اخیستل کیږي.
کله چې بله تېروتنه ښکاره شي، د عملیاتو نوم واخلئ: د CA فایل لوستل، د مقابل لوري تصدیق تصدیق کول، یا د client هویت وړاندې کول. د پیغام تر بدلېدو پورې د verify او cert ترمنځ فایل لېږدول د هغې رول غوره کولو باوري لاره نه ده.