Chrome onAuthRequired: праверце isProxy перад адпраўкай уліковых даных
Зваротны выклік аўтэнтыфікацыі Chrome можа апісваць выклік проксі або выклік крыніцы. Падача адных і тых жа ўліковых даных абодвум — памылка ў абсягу ўліковых даных.
Пашырэнне браўзера можа сутыкнуцца з выклікамі аўтэнтыфікацыі з двух розных месцаў: проксі, які перадае запыт, і вэб-сайт прызначэння. Яны не павінны аўтаматычна атрымаць адзін і той жа ўліковы запіс.
Карысны адрознівальнік у падзеі Chrome webRequest.onAuthRequired — гэта isProxy. Зваротны выклік, які выдаляе гэтую праверку проста дзеля таго, каб знік запыт, можа пачаць падаваць уліковыя даныя проксі на выклік крыніцы.
Супрацоўнічайце з проксі, якому маеце намер давяраць
Праверка isProxy — гэта пачатак. Абмяжуйце таксама апрацоўку чаканым выклікам проксі і кантэкстам запыту. Пашырэнне, якое кіруе некалькімі канчатковымі пунктамі, павінна выбіраць уліковы запіс, які належыць гэтаму пункту, а не адзіны глабальны пароль для кожнага выкліку.
Не мяркуйце, што наладка маршруту проксі і апрацоўка яго ўваходу — гэта адно дазвол або адзін выклік API. Chrome дакументуе іх асобна. Выкарыстоўвайце актуальную даведку webRequest для даных падзей і дазволаў аўтэнтыфікацыі. Прыклад рэгістрацыі слухача Manifest V3 паказвае сінхронную рэгістрацыю і выбар уліковага запісу ўнутры зваротнага выкліку.
Праверце пакаленне маніфеста
Прыклады, якія згадваюць эксперыментальны API WebRequest, паходзяць са старых выпускаў пашырэнняў. Актуальныя патрабаванні да дазволаў залежаць ад пакалення маніфеста пашырэння і мадэлі разгортвання. У прыватнасці, апрацоўка аўтэнтыфікацыі мае свой уласны падтрыманы шлях дазволаў; састарэлы прыклад блакуючага слухача недастатковы, каб даказаць, што пашырэнне Manifest V3 можа выконваць яго без змен.
Правільны апрацоўшчык таксама павінен пазбягаць бясконцага паўтору адных і тых жа адхіленых уліковых даных. Успрымайце другі выклік пасля прадстаўленага ўліковага запісу як падставу для расследавання, а не як запыт на вечнае паўтарэнне пароля.
Уліковыя даныя павінны заставацца ў адпаведным абароненым шляху апрацоўкі пашырэння. Не публікуйце іх у файле PAC і не ўбудоўвайце ў распаўсюджваны прыклад. Мэта — вузка абмежаваны ўваход праз проксі, а не агульнабраўзернае правіла, якое адказвае на кожны выклік аўтэнтыфікацыі адным і тым жа сакрэтам.