Как обрабатывать пароли прокси со специальными символами в Python Requests

При настройке прокси в Python Requests часто возникает ситуация, когда учетные данные работают в другом инструменте, но перестают работать после добавления в URL. Причина может заключаться в способе представления имени пользователя и пароля, особенно если они содержат такие символы, как @, :, /, # или %.

Чтобы правильно обрабатывать пароли прокси со специальными символами, необходимо отличать учетные данные от синтаксиса URL. Решение — применять процентное кодирование к каждому компоненту учетных данных отдельно и только после этого собирать адрес прокси.

Почему специальные символы приводят к неправильному разбору URL прокси?

URL прокси с аутентификацией обычно имеет структуру scheme://username:password@host:port. Двоеточие отделяет имя пользователя от пароля, а символ @ обозначает конец части с учетными данными.

Если пароль содержит символы, имеющие синтаксическое значение, и вставляется в URL напрямую, анализатор может неверно определить границы компонентов. Например, символ # может обозначать начало фрагмента, а символ / — начало пути.

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

Символы, на которые стоит обратить внимание

• @ и : непосредственно связаны со структурой учетных данных.
• / и ?: имеют значение при определении пути и строки запроса.
• #: может восприниматься как символ начала фрагмента.
• %: обозначает начало последовательности процентного кодирования.
• Пробелы и символы Unicode: необходимо преобразовывать в представление, подходящее для URL.

Что такое процентное кодирование для прокси?

Процентное кодирование для прокси — это способ представления символов с помощью знака процента и шестнадцатеричного значения соответствующего байта. Например, символ @ представляется как %40, символ # — как %23, а символ % — как %25.

В Python для этого используется функция urllib.parse.quote. При обработке имени пользователя и пароля в URL прокси следует передавать safe='', чтобы не сохранять косую черту, как это происходит по умолчанию.

Важно: процентное кодирование не является шифрованием. Любой, кто получит URL, сможет восстановить учетные данные. Поэтому URL прокси, содержащий учетные данные, необходимо защищать так же, как сам пароль.

Как правильно кодировать URL прокси в Python

Кодируйте имя пользователя и пароль отдельно

Главное правило — кодировать только отдельные компоненты учетных данных. Не применяйте quote ко всему URL, поскольку это преобразует и необходимые разделители.

В следующем примере для наглядности используются вымышленные данные:

from urllib.parse import quote

username = 'user@example'

password = 'p@ss:word/#%'

encoded_username = quote(username, safe='')

encoded_password = quote(password, safe='')

В результате имя пользователя превращается в user%40example, а пароль — в p%40ss%3Aword%2F%23%25. Символы, относящиеся к учетным данным, больше не будут ошибочно восприниматься как разделители URL.

Собирайте URL после кодирования

Только после предыдущего шага следует объединять компоненты в URL прокси. В следующем примере адрес и порт берутся из переменных окружения:

import os

proxy_host = os.environ['PROXY_HOST']

proxy_port = os.environ['PROXY_PORT']

proxy_url = f'http://{encoded_username}:{encoded_password}@{proxy_host}:{proxy_port}'

В примере предполагается, что PROXY_HOST — это допустимое имя хоста или IPv4-адрес без схемы и учетных данных. Если используется IPv6-адрес в буквальной форме, адресную часть URL необходимо заключить в квадратные скобки.

Полная настройка прокси в Python Requests

В реальном приложении имя пользователя и пароль следует получать из источника конфигурации, а не прописывать непосредственно в исходном коде. Приведенный ниже код создает URL из исходных учетных данных, а затем настраивает Session:

import os

import requests

from urllib.parse import quote

username = quote(os.environ['PROXY_USERNAME'], safe='')

password = quote(os.environ['PROXY_PASSWORD'], safe='')

host = os.environ['PROXY_HOST']

port = os.environ['PROXY_PORT']

proxy_url = f'http://{username}:{password}@{host}:{port}'

session = requests.Session()

session.trust_env = False

session.proxies.update({'http': proxy_url, 'https': proxy_url})

response = session.get(os.environ['TARGET_URL'], timeout=float(os.environ['REQUEST_TIMEOUT']))

response.raise_for_status()

В этой конфигурации REQUEST_TIMEOUT должен содержать допустимое значение времени ожидания, выбранное для приложения. TARGET_URL должен указывать на ресурс, к которому у вас есть право доступа для проверки соединения.

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

Различайте ключ https и схему прокси

Ключ 'https' в словаре proxies задает прокси для целевых URL с HTTPS. Он не означает, что URL прокси обязательно должен начинаться с https://.

Если провайдер предоставляет HTTP-прокси, один и тот же URL, начинающийся с http://, можно использовать для обоих ключей. Для целевых ресурсов HTTPS соединение обычно устанавливается с помощью метода CONNECT. Используйте схему https:// для прокси только в том случае, если сервис действительно поддерживает TLS-соединение с прокси.

Типичные ошибки при обработке специальных символов

Кодирование всего URL

Вызов quote(proxy_url, safe='') не подходит, если proxy_url уже содержит полный адрес. Он кодирует в том числе двоеточие и косые черты в схеме, из-за чего результат перестает соответствовать правильной структуре URL прокси.

Оставляйте схему, хост, порт и разделители без изменений. Применяйте quote только к username и password перед сборкой URL.

Повторное кодирование данных, уже прошедших процентное кодирование

Если исходный пароль содержит @, результат кодирования — %40. При повторном кодировании этой строки символ % превращается в %25, и получается %2540. Данные, отправляемые прокси, могут перестать соответствовать исходному паролю.

Следует четко определить, что на вход функции создания URL поступают исходные учетные данные. Не декодируйте автоматически все строки со знаком %, поскольку настоящий пароль может буквально содержать последовательность %40.

Использование quote_plus вместо quote

Функция quote_plus обычно предназначена для данных форм и соглашений о представлении строк запроса, где пробел заменяется знаком плюса. Для части URL с учетными данными не следует по умолчанию использовать это соглашение.

Чтобы однозначно представить пробелы в username или password, используйте quote(value, safe=''). Пробел будет преобразован в %20.

Путаница между аутентификацией прокси и аутентификацией на целевом сервере

Параметр auth= в Requests обычно используется для аутентификации на целевом сервере и в этой ситуации не является прямой заменой учетным данным прокси. Аналогично не следует самостоятельно добавлять учетные данные прокси в заголовок Authorization, отправляемый веб-сайту.

Добавление учетных данных в URL подходит для прокси, использующих механизм аутентификации, который Requests поддерживает при такой настройке, — обычно Basic. Если прокси требует другой механизм, потребуется соответствующее решение для аутентификации; процентное кодирование решает только задачу представления данных.

Порядок проверки, если прокси по-прежнему не работает

После исправления кодирования URL прокси выполняйте проверку поэтапно, вместо того чтобы продолжать менять пароль наугад:

1. Проверьте входные данные: убедитесь, что учетная запись действительна и в данных нет случайных пробелов или символов перевода строки.
2. Проверьте структуру URL: убедитесь, что хост, порт и схема соответствуют данным провайдера.
3. Проверьте этап кодирования: убедитесь, что quote применяется к исходным username и password только при создании URL.
4. Проверьте соединение: различайте ошибки разрешения доменных имен, ошибки подключения, тайм-ауты и ошибки аутентификации.
5. Проверьте настройки окружения: выясните, влияют ли HTTP_PROXY, HTTPS_PROXY и NO_PROXY на запрос.
6. Проверьте правила сервиса: уточните, требует ли прокси регистрации исходного IP-адреса и действуют ли соответствующие ограничения доступа.

Ответ с требованием аутентификации на прокси обычно связан с учетной записью, паролем или механизмом аутентификации. В то же время ошибки сертификатов и установки туннеля могут быть связаны с TLS, схемой или политикой соединений. Не следует считать любую ошибку Requests проблемой специальных символов.

Также не стоит использовать verify=False для решения этой проблемы. Этот параметр отключает проверку TLS-сертификата соответствующего соединения, но не исправляет неправильно разобранный URL.

Защита учетных данных при ведении журналов и развертывании

Не выводите proxy_url на экран и не передавайте полный URL в систему отслеживания ошибок. Строка после процентного кодирования по-прежнему содержит учетные данные, которые можно восстановить. Сообщения исключений также необходимо проверять перед сохранением или передачей другим лицам.

• Храните учетные данные в системе управления секретами или используйте подходящий механизм конфигурации.
• При диагностике записывайте только хост, порт и результат проверки.
• Скрывайте и username, и password в обращениях в службу поддержки.
• Смените учетные данные, если полный URL оказался в открытом доступе.

Безопасность канала связи с прокси необходимо оценивать отдельно. Процентное кодирование не защищает пароль от перехвата при передаче; при использовании HTTP-прокси с аутентификацией Basic учетные данные прокси не становятся защищенными TLS на участке до прокси лишь потому, что целевой веб-сайт использует HTTPS.

Заключение

Для обработки паролей прокси со специальными символами используйте urllib.parse.quote с safe='' отдельно для username и password и только затем собирайте URL. Кроме того, необходимо договориться об использовании исходных входных данных, чтобы избежать повторного кодирования.

При настройке прокси в Python Requests дополнительно проверяйте схему, механизм аутентификации и влияние окружения. Такой подход помогает отличать ошибки представления URL от ошибок соединения и снижает риск раскрытия учетных данных во время диагностики.