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 लॉगिन पृष्ठापेक्षा वेगळा प्रोटोकॉल आहे.

टोकन त्याच्या प्रॉक्सी एंडपॉइंट आणि इच्छित आयुष्यापर्यंत मर्यादित ठेवा. दुसऱ्या मध्यस्थाकडे जाताना, त्या कॉन्फिगरेशन बदलाचा भाग म्हणून हेडर सूची बदला. सामान्य विनंती-हेडर सूची केवळ एका प्रॉक्सीच्या रहस्यासाठी वाईट जागा आहे.