PHP cURL में प्रॉक्सी प्रमाणीकरण विकल्प
सही cURL विकल्पों से प्रॉक्सी क्रेडेंशियल सेट करें और गंतव्य प्रमाणीकरण बदले बिना संयुक्त फ़ील्ड का URL डिकोडिंग संभालें।
प्रॉक्सी प्रमाणीकरण के अपने cURL विकल्प हैं। वेबसाइट लॉगिन के लिए CURLOPT_USERPWD सेट करना प्रॉक्सी खाता सेट नहीं करता, और CURLOPT_HTTPAUTH प्रॉक्सी प्रमाणीकरण विधि नहीं चुनता।
<?php
$user = 'proxy-user';
$password = getenv('PROXY_PASSWORD');
if ($password === false) {
throw new RuntimeException('Set PROXY_PASSWORD');
}
$ch = curl_init('https://example.com/');
curl_setopt_array($ch, [
CURLOPT_PROXY => 'http://203.0.113.10:8080',
CURLOPT_NOPROXY => '',
CURLOPT_PROXYUSERPWD =>
rawurlencode($user) . ':' . rawurlencode($password),
CURLOPT_PROXYAUTH => CURLAUTH_BASIC,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_CONNECTTIMEOUT => 5,
CURLOPT_TIMEOUT => 15,
]);
$body = curl_exec($ch);
if ($body === false) {
throw new RuntimeException(curl_error($ch), curl_errno($ch));
}
echo curl_getinfo($ch, CURLINFO_RESPONSE_CODE), PHP_EOL;
दस्तावेज़ी IP बदलें और उस प्रॉक्सी के दिए क्रेडेंशियल लें। इस उदाहरण में Basic जानबूझकर चुना गया है; हर एंडपॉइंट को इसकी जरूरत मानने के बजाय सेवा की समर्थित और स्वीकृत विधि लें।
संयुक्त फ़ील्ड का एन्कोडिंग नियम है
libcurl बताता है कि CURLOPT_PROXYUSERPWD उपयोगकर्ता नाम और पासवर्ड को URL-डिकोड करता है। उदाहरण हर भाग को विभाजक से जोड़ने से पहले एन्कोड करता है। जब वास्तविक प्रतिशत क्रम या दूसरा विशेष अक्षर क्रेडेंशियल में हो, यह महत्त्वपूर्ण है।
अलग प्रॉक्सी उपयोगकर्ता नाम और पासवर्ड विकल्प अपने मान सीधे लेते हैं:
curl_setopt($ch, CURLOPT_PROXYUSERNAME, $user);
curl_setopt($ch, CURLOPT_PROXYPASSWORD, $password);
अनुरोध चलाने से पहले इन्हें क्रेडेंशियल के वैकल्पिक रूप की तरह लें। संयुक्त प्रॉक्सी फ़ील्ड का डिकोडिंग नियम अपने आप CURLOPT_USERPWD पर न लगाएँ; libcurl इनके बीच अंतर बताता है।
प्रमाणीकरण के चरण अलग रखें
CURLOPT_PROXYAUTH प्रॉक्सी प्रमाणीकरण चुनता है और CURLOPT_HTTPAUTH गंतव्य का HTTP प्रमाणीकरण। दोनों लॉगिन माँगें तो हर एक के उचित विकल्प दें, एक ही क्रेडेंशियल दोनों जगह न कॉपी करें।
CURLAUTH_ANY बातचीत की अनुमति देता है और विधि चुने जाने से पहले चुनौती-जवाब का आदान-प्रदान जोड़ सकता है। यह क्रेडेंशियल सही होने का प्रमाण नहीं है। अतिरिक्त Proxy-Authorization हेडर खुद जोड़ना लाइब्रेरी के प्रमाणीकरण में बाधा डाल सकता है।
प्रॉक्सी तक स्पष्ट-पाठ कनेक्शन के Basic क्रेडेंशियल वेबसाइट की बाद की TLS टनल से सुरक्षित नहीं होते। प्रमाणीकरण वाली सेवा का उपयोग चुनते समय उस ट्रांसपोर्ट को अलग जाँचें।