HTTP 407 или 401: која најава не успева?
Одвојте ја автентикацијата на проксито од онаа на веб-локацијата, проверете ги вистинските заглавија и не праќајте податоци за најава на погрешна страна.
407 бара автентикација на проксито. 401 ја бара за целниот ресурс. Едно барање може да ги сретне и двата одговора, па пред да дадете лозинка утврдете кој ја бара.
Споредете ги статусот и заглавијата за автентикациски предизвик
| Одговор | Заглавие за предизвик | Заглавие со податоци за најава | Вклучена страна |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Посредничко прокси |
| 401 Unauthorized | WWW-Authenticate | Authorization | Текот на автентикација на изворниот ресурс |
Статусот е важен прв показател, но разгледајте ја целата размена. Бројот 407 во текстот на страница не е вистински HTTP 407 одговор. И прилагодена страница за најава може да врати 200 и сè уште да бара автентикација на апликациско ниво.
Зошто HTTPS може да откаже со 407 пред да стигне до веб-локацијата
Кога обично HTTP прокси пренесува HTTPS барање, клиентот најчесто прво бара CONNECT тунел. Проксито може да бара автентикација за тоа CONNECT барање. Ако не заврши, TLS сесијата со одредиштето низ тунелот сè уште не е воспоставена. Менување на API токенот на веб-локацијата веројатно нема да ја поправи таа фаза.
Со детален излез видете каде се појавува предизвикот:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Заменете го локалниот слушател со својот и прочитајте го првиот предизвик во дневникот. 407 за време на CONNECT доаѓа пред TLS на одредиштето; подоцнежен 401 може да следува по успешно воспоставен тунел.
Податоците за проксито дајте ги преку неговиот интерфејс
За крајна точка и сметка од доверлив администратор, curl може да ја договори шемата за автентикација и да ја побара ненаведената лозинка:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Заменете ги примерните крајна точка и корисник со податоци од услугата што смеете да ја користите. Само корисничкото име ја избегнува лозинката непосредно во горната команда. Поддржаните методи зависат од изданието на curl и проксито; при неуспешен договор проверете го вистинскиот предизвик и можностите на изданието.
Опцијата за автентикација на проксито е одвоена од curl-овата корисничка автентикација на изворниот сервер. Не додавајте Authorization заглавие за изворот наместо одговор на предизвикот од проксито. Не препраќајте рачно заглавија со податоци за проксито кон неповрзани барања и не чувајте ги во заглавија што повторно ги користи целата апликација.
Ако проксито постојано враќа 407
- Потврдете дека ги користите предвидените хост и порта на проксито.
- Проверете ги шемите што ги објавува проксито наместо да претпоставите Basic.
- Потврдете ги состојбата на сметката и бараниот формат на корисничкото име.
- Проверете го преносот на посебни знаци ако податоците се во URL.
- Утврдете дали деловната автентикација интегрирана со прелистувачот бара поддршка од извршната околина или платформата.
- Ако доказите на клиентот не се доволни, побарајте од администраторот идентификатор на барање или серверски запис без чувствителни податоци.
403 или одбиен CONNECT може да биде одлука на правилата за пристап и по успешна најава. Повеќе обиди за лозинка нема да отворат забрането одредиште.
HTTPS на одредиштето не ја штити секоја размена на податоци за проксито
Автентикацијата на проксито може да се случи пред TLS на одредиштето. Ако врската со самото прокси е нешифрирана и методот таму открива податоци за повторна употреба, HTTPS одредиштето не ја штити претходната размена отпосле. Изберете соодветни пренос и автентикација за услугата; не испраќајте приватни сметки на непознато јавно прокси.
Пред споделување прегледајте ги деталните дневници. И ако алатката ги прикрива вообичаените полиња за најава, може да останат корисници, имиња на внатрешни крајни точки, колачиња или други идентификациски податоци.