HTTP 407 без прыдатнага выкліку Proxy-Authenticate
Праверце загаловак аўтэнтыфікацыі проксі, калі кліент ніколі не выклікае свой апрацоўшчык уліковых даных або атрымлівае нечаканы статус замест звычайнага выкліку.
Кліент не можа выбраць механізм аўтэнтыфікацыі, грунтуючыся толькі на нумары статусу. Адказ проксі павінен апісваць, што ён прымае.
HTTP патрабуе, каб проксі, які стварае 407, дасылаў выклік Proxy-Authenticate. Для службы Basic просты прыклад:
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"Лікавы статус, імя загалоўка і сінтаксіс, спецыфічны для схемы, — усё гэта важна. Брэндаваная старонка памылкі са словам authentication у целе не замяняе загаловак. Уласныя рэалізацыі таксама павінны дасылаць поўны адказ HTTP 407, уключаючы завяршальнік загалоўка і фарміраванне цела.
Праверце адказ, які дайшоў да гэтага кліента
Зафіксуйце палі статусу і выкліку, выдаліўшы сакрэтныя значэнні. Пасрэднік мог пераўтварыць адказ, або ўласны проксі мог пабудаваць несапраўдны выклік. Параўнайце гэтыя доказы з уласным журналам транзакцый проксі.
Калі служба замест гэтага дасылае 405 або іншую памылку, не перамаркоўвайце кожны такі адказ як 407 ва ўласным кліенце. Вы схавалі б сапраўдныя збоі палітыкі метадаў і ўсё роўна не мелі б надзейнага ўзгаднення схемы. Выпраўце паводзіны службы або выкарыстайце яе дакументаваны падтрыманы шлях аўтэнтыфікацыі.
Некалькі выклікаў таксама патрабуюць сапраўднага парсера HTTP. Коска можа раздзяляць параметры або выклікі; сляпое раздзяленне ўсяго загалоўка па косках можа пашкодзіць realm у двукоссях. Выкарыстоўвайце падтрыманую рэалізацыю аўтэнтыфікацыі кліента, а не паслядоўнасць замен радкоў.
Толькі пасля таго, як выклік стаў прыдатным, мае сэнс даследаваць, чаму пастаўшчык уліковых даных не вярнуў уліковы запіс.