Прокси с логином и паролем в Selenium: почему сломались все старые рецепты

Четыре удаления, а не одно

Обычно всё сводят к смерти Manifest V2, и это неточно: для Selenium главная потеря другая. В Chrome 137 из брендированных сборок убрали флаг --load-extension — именно им подкладывалось сгенерированное расширение, и это ломает рецепт независимо от версии манифеста. Chrome 138 стал последним, где MV2-расширения ещё могли запускаться. В Chrome 139 убрали политику ExtensionManifestV2Availability и флаги --disable-extensions-except и --extensions-on-chrome-urls. В Chrome 142 убрали и временный флаг-выключатель, которым это всё обходили.

MV3 умеет авторизацию — искать надо не здесь

Распространённое заблуждение: будто в Manifest V3 авторизация на прокси стала невозможной. Это не так. Блокирующий webRequest в MV3 действительно недоступен большинству расширений, но у обработчика onAuthRequired сделали исключение: он остаётся блокирующим, если запросить разрешение webRequestAuthProvider. То есть код расширения писать можно; сложность целиком в том, как его загрузить в брендированный Chrome.

// Минимум, который нужен расширению для авторизации на прокси в MV3
{
  "manifest_version": 3,
  "permissions": ["proxy", "webRequest", "webRequestAuthProvider", "storage"],
  "host_permissions": ["<all_urls>"],
  "background": { "service_worker": "background.js" }
}

Почему selenium-wire больше не выход

Библиотека заархивирована 3 января 2024 года и на PyPI осталась на версии 5.1.0. Ломается она на современном Python характерной ошибкой ModuleNotFoundError: No module named 'blinker._saferef', и вся причина — две строки импорта во вложенной копии mitmproxy: import blinker и import blinker._saferef. Приватный модуль _saferef удалён в blinker 1.8.0, вышедшем 27 апреля 2024 года, а в зависимостях selenium-wire указано blinker без верхней границы.

# Заплатка, если проект уже завязан на selenium-wire:
# последняя версия blinker, где _saferef ещё есть
pip install 'blinker==1.7.0'

# Живые продолжения (имена важны, оба существуют на PyPI):
pip install selenium-wire-2
pip install selenium-wire-lw

Оба продолжения под капотом остаются man-in-the-middle прокси на mitmproxy, то есть тянут за собой сертификат и накладные расходы. Это рабочий путь, но самый хрупкий из имеющихся.

Что советуют, но что не работает

• Proxy(socks_username=..., socks_password=...) — наследие старого протокола: этих ключей нет в таблице возможностей W3C, и спецификация требует ошибки на нераспознанные ключи.
• driver.register(логин, пароль) — такого метода в текущем Selenium для Python нет. Проверка через hasattr возвращает True только потому, что метод унаследован от abc.ABCMeta.
• Учётные данные внутри адреса прокси — Chrome их игнорирует по своей же документации.
• BiDi-обработчик driver.network.add_auth_handler — сам метод есть, но авторизация именно на прокси в Chrome через него не работает: это открытый подтверждённый баг.

Четыре пути, которые работают

• Не авторизовываться в браузере вовсе: поднять локальный прокси без пароля, который подставляет учётные данные вверх по цепочке. У mitmproxy это режим upstream плюс опция upstream_auth. Для Chrome это к тому же единственный способ использовать SOCKS5 с авторизацией.
• CDP: включить Fetch с обработкой авторизации и отвечать на событие authRequired командой continueWithAuth. В протоколе прокси предусмотрен явно — источник вызова различает Server и Proxy.
• MV3-расширение, установленное не флагом, а через BiDi: Selenium умеет устанавливать расширения командой webextension.install, и для Chrome к этому нужны ключи запуска для отладки расширений и режим удалённой отладки через pipe.
• Обойти брендированный Chrome: в Chromium и Chrome for Testing флаг --load-extension продолжает работать, так что классический рецепт там жив — если перенести манифест на третью версию.

В Firefox всё проще

У WebExtension-API Firefox есть поле proxyAuthorizationHeader, которое передаётся прямо в заголовок Proxy-Authorization при CONNECT. Никакого обмена «запрос — ответ» не требуется, значение подставляется сразу. Ограничение одно: только HTTP и HTTPS-прокси, для SOCKS это не работает.

Или не авторизовываться совсем

Все четыре пути выше существуют ради одного: передать пароль браузеру, который этого не хочет. Есть более короткий выход — не передавать. При авторизации по IP адрес машины добавляется в whitelist, прокси узнаёт клиента по подключению, и в настройках остаётся только хост с портом. Для SOCKS5 в Chrome это вообще единственный способ без локального релея, потому что авторизацию SOCKS5 Chromium не поддерживает в принципе.

У нас оба способа активны одновременно, так что переключать ничего не нужно: машина с автотестами работает по whitelist, а остальное продолжает ходить по логину и паролю. Проверено на Selenium 4.47 и Chrome 152.