Сохранение прокси-cookie в запросе CONNECT

Используйте отдельный интерфейс прокси-заголовков libcurl для определённого поставщиком входа через CONNECT, а не рассматривайте cookie назначения как прокси-аутентификацию.

Некоторые прокси-продукты определяют процесс входа, который выдаёт 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 браузера — другой механизм

Включение механизма cookie libcurl или установка cookie для назначения не воспроизводит автоматически собственный процесс входа браузера через прокси. CONNECT происходит до обмена HTTPS с назначением. Определите фактические требования продукта, а не копируйте перехваченный cookie сайта в каждый запрос.

Если прокси использует стандартную аутентификацию HTTP-прокси, используйте вместо этого учётные данные прокси libcurl и поддерживаемые параметры аутентификации. 407 с Proxy-Authenticate — это другой протокол, чем HTML-страница входа, возвращающая токен сеанса.

Ограничьте токен его конечной точкой прокси и предполагаемым сроком жизни. При переходе к другому посреднику замените список заголовков как часть этого изменения конфигурации. Общий список заголовков запроса — плохое место для секрета, принадлежащего только одному прокси.

Похожие статьи