Аутентифікація через проксі в Chrome CDP: обробка обох шляхів подій Fetch

Увімкніть запити автентифікації до навігації, продовжуйте звичайні призупинені запити й відповідайте лише на потрібний виклик Proxy з обмеженою політикою спроб.

У відповідній сесії CDP зареєструйте обробники до навігації, потім викличте Fetch.enable з цими параметрами:

{"handleAuthRequests": true}
ПодіяПотрібний шлях відповіді
Fetch.requestPausedcontinueRequest з тим самим requestId, коли звичайна робота має продовжуватися
Fetch.authRequiredПеревірте authChallenge, потім використайте continueWithAuth з requestId події автентифікації

Для розпізнаного посередника параметри автентифікації такі:

{
  "requestId": "REQUEST_ID_FROM_AUTH_EVENT",
  "authChallengeResponse": {
    "response": "ProvideCredentials",
    "username": "PROXY_USERNAME",
    "password": "PROXY_PASSWORD"
  }
}

Перед завантаженням облікового запису з джерела облікових даних перевірте, що authChallenge.source дорівнює Proxy і його джерелом є очікуваний ініціатор виклику. Виклик Server дотримується іншої політики автентифікації.

Відстежуйте дозволені спроби для кожного перехопленого запиту; повторно відхилений виклик має отримати CancelAuth, а не чергове нескінченне надсилання. Очищайте відстеження після завершення або закриття сесії.

Якщо сторінка зависає, перевірте й невирішені події requestPaused. Обробка автентифікації не продовжує їх автоматично, і жоден зі шляхів подій не вибирає проксі-маршрут браузера.

Схожі статті