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 መካከል መልእክቱ እስኪቀየር ማንቀሳቀስ ሚናውን ለመምረጥ አስተማማኝ መንገድ አይደለም።

ተዛማጅ ጽሑፎች