一部のプロキシ製品は、後続のプロキシリクエスト用のCookieまたはトークンを提供するログインフローを定義しています。そのトークンをCONNECTに表示する必要がある場合は、トンネル内のウェブサイト向けのCookieとは分けて保持してください。

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でプロキシリストを、確立されたトンネル内のリクエストで宛先リストを送信します。したがってプロキシはベンダーのトークンを受け取りますが、そのトークンがウェブサイトのCookieになることはありません。この分離はlibcurl 7.42.1以降のデフォルトです。明示的なオプションは意図された動作を可視化します。

ブラウザのCookieジャーは別の仕組みです

libcurlのCookieエンジンを有効にしたり宛先のCookieを設定したりしても、ブラウザ独自のプロキシログインフローが自動的に再現されるわけではありません。CONNECTは宛先とのHTTPS交換より前に発生します。キャプチャしたサイトCookieをすべてのリクエストにコピーするのではなく、製品の実際の要件を特定してください。

プロキシが標準のHTTPプロキシ認証を使用する場合は、代わりにlibcurlのプロキシ資格情報とサポートされている認証オプションを使用してください。Proxy-Authenticateを伴う407は、セッショントークンを返すHTMLログインページとは異なるプロトコルです。

トークンはプロキシのエンドポイントと意図された寿命の範囲内に保ってください。別の中間者に切り替えるときは、その設定変更の一部としてヘッダーリストを置き換えてください。一般的なリクエストヘッダーリストは、1つのプロキシだけに属する秘密の置き場所としては不適切です。

関連記事