Аўтэнтыфікацыя праз проксі ў 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. Апрацоўка аўтэнтыфікацыі не працягвае іх аўтаматычна, і ні адзін шлях падзей не выбірае маршрут проксі браўзэра.

Падобныя артыкулы