Python Requests: CA બંડલ verify માં રહે છે, cert માં નહીં
મંજૂર CA વિશ્વાસ સામગ્રીને verification રૂપરેખાંકનમાં મૂકો, પ્રમાણપત્રની ભૂલને ક્લાયન્ટની ખાનગી કીની વિનંતી તરીકે ગણવાને બદલે.
એક સહકર્મી તમને સંસ્થાનું 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 વચ્ચે ફાઇલ ખસેડવી તેની ભૂમિકા પસંદ કરવાનો વિશ્વસનીય રસ્તો નથી.