Pagpapanatili ng cookie ng proxy sa kahilingang CONNECT

Ang ilang produkto ng proxy ay nagtatakda ng login flow na nagbibigay ng cookie o token para sa mga susunod na kahilingan ng proxy. Kung kailangang lumitaw ang token na iyon sa CONNECT, panatilihin itong hiwalay sa mga cookie na inilaan para sa website sa loob ng tunnel.

Nagbibigay ang libcurl ng dedikadong listahan ng custom na header para sa proxy. Sa isang C application na nasimulan na, ang isang bahagi ng configuration ay maaaring magmukhang ganito:

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);

Angkop lamang ito kapag hinihiling ng dokumentadong login protocol ng proxy ang header na iyon. Suriin ang mga resulta ng allocation at mga opsyon sa paligid ng code, panatilihin ang listahan hanggang matapos ang paglilipat, pagkatapos ay i-clear o palitan ang pointer ng handle bago palayain ang listahan.

Sa hiwalay na paghawak ng header, ipinapadala ng libcurl ang listahan ng proxy sa CONNECT at ang listahan ng destinasyon sa kahilingan sa loob ng itinatag na tunnel. Kaya natatanggap ng proxy ang token ng vendor nang hindi nagiging cookie ng website ang token na iyon. Ang paghihiwalay na ito ay default mula sa libcurl 7.42.1; ginagawang nakikita ng tahasang opsyon ang nilalayong pag-uugali.

Ang jar ng cookie ng browser ay ibang mekanismo

Ang pagpapagana ng cookie engine ng libcurl o pagtatakda ng cookie para sa destinasyon ay hindi awtomatikong nagre-reproduce ng proprietary na proxy-login flow ng browser. Ang CONNECT ay nangyayari bago ang HTTPS exchange sa destinasyon. Tukuyin ang aktwal na mga pangangailangan ng produkto sa halip na kopyahin ang nakuhang cookie ng site sa bawat kahilingan.

Kung gumagamit ang proxy ng standard na HTTP proxy authentication, gamitin sa halip ang mga kredensyal ng proxy ng libcurl at ang mga sinusuportahang opsyon sa authentication. Ang 407 na may Proxy-Authenticate ay ibang protocol kaysa sa HTML login page na nagbabalik ng session token.

Panatilihing limitado ang token sa endpoint ng proxy nito at sa nilalayong tagal. Kapag lumilipat sa ibang tagapamagitan, palitan ang listahan ng header bilang bahagi ng pagbabago sa configuration na iyon. Ang pangkalahatang listahan ng request header ay masamang lugar para sa isang lihim na pag-aari lamang ng isang proxy.