CONNECT अनुरोध पर प्रॉक्सी कुकी रखना

कुछ प्रॉक्सी उत्पाद ऐसा लॉगिन प्रवाह परिभाषित करते हैं जो आगे के प्रॉक्सी अनुरोधों के लिए कुकी या टोकन देता है। यदि वह टोकन CONNECT पर दिखना चाहिए, तो इसे टनल के भीतर वेबसाइट के लिए इच्छित कुकीज़ से अलग रखें।

libcurl प्रॉक्सी के लिए एक समर्पित कस्टम-हेडर सूची प्रदान करता है। पहले से आरंभ किए गए C अनुप्रयोग में, कॉन्फ़िगरेशन का एक अंश ऐसा दिख सकता है:

struct curl_slist *proxy_headers = NULL;
proxy_headers = curl_slist_append(proxy_headers,
    "Cookie: ProxySession=REPLACE_WITH_PROXY_TOKEN");
curl_easy_setopt(handle, CURLOPT_PROXYHEADER, proxy_headers);
curl_easy_setopt(handle, CURLOPT_HEADEROPT,
                 (long) CURLHEADER_SEPARATE);

यह केवल तब उपयुक्त है जब प्रॉक्सी का प्रलेखित लॉगिन प्रोटोकॉल उस हेडर की मांग करता हो। आसपास के कोड में आवंटन और विकल्पों के परिणाम जांचें, स्थानांतरण पूरा होने तक सूची रखें, फिर सूची मुक्त करने से पहले हैंडल के सूचक को साफ़ या बदलें।

अलग हेडर प्रबंधन के साथ, libcurl प्रॉक्सी सूची CONNECT पर और गंतव्य सूची स्थापित टनल के भीतर अनुरोध पर भेजता है। इस तरह प्रॉक्सी को विक्रेता टोकन मिलता है, पर वह टोकन वेबसाइट कुकी नहीं बनता। यह पृथक्करण libcurl 7.42.1 से डिफ़ॉल्ट है; स्पष्ट विकल्प इच्छित व्यवहार को दृश्यमान बनाता है।

ब्राउज़र कुकी जार एक और तंत्र है

libcurl का कुकी इंजन सक्षम करना या गंतव्य के लिए कुकी सेट करना ब्राउज़र के स्वामित्व वाले प्रॉक्सी-लॉगिन प्रवाह को स्वचालित रूप से पुन: उत्पन्न नहीं करता। CONNECT गंतव्य के HTTPS आदान-प्रदान से पहले होता है। हर अनुरोध में कैप्चर की गई साइट कुकी कॉपी करने के बजाय उत्पाद की वास्तविक आवश्यकताएं पहचानें।

यदि प्रॉक्सी मानक HTTP प्रॉक्सी प्रमाणीकरण का उपयोग करता है, तो इसके बजाय libcurl के प्रॉक्सी क्रेडेंशियल और समर्थित प्रमाणीकरण विकल्प उपयोग करें। Proxy-Authenticate के साथ 407 सत्र टोकन लौटाने वाले HTML लॉगिन पृष्ठ से भिन्न प्रोटोकॉल है।

टोकन को उसके प्रॉक्सी एंडपॉइंट और इच्छित जीवनकाल तक सीमित रखें। किसी अन्य मध्यस्थ पर जाते समय, उस कॉन्फ़िगरेशन परिवर्तन के भाग के रूप में हेडर सूची बदलें। सामान्य अनुरोध-हेडर सूची केवल एक प्रॉक्सी के रहस्य के लिए बुरी जगह है।