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 লগইন পৃষ্ঠা যা সেশন টোকেন ফেরত দেয় তার থেকে ভিন্ন প্রোটোকল।

টোকেনটি তার প্রক্সি এন্ডপয়েন্ট ও অভিপ্রেত আয়ুষ্কালে সীমাবদ্ধ রাখুন। অন্য এক মধ্যস্থতাকারীতে পরিবর্তনের সময় সেই কনফিগারেশন পরিবর্তনের অংশ হিসেবে হেডার তালিকাটি প্রতিস্থাপন করুন। সাধারণ অনুরোধ-হেডার তালিকা কেবল একটি প্রক্সির জন্য প্রযোজ্য গোপন তথ্যের জন্য খারাপ জায়গা।