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 целта не защитава този обмен със задна дата. Изберете подходящи за услугата транспорт и удостоверяване; не изпращайте лични акаунти към непознато публично прокси.
Прегледайте подробните журнали, преди да ги споделяте. Дори инструментът да скрива обичайните полета за вход, може да останат потребителски имена, вътрешни крайни точки, бисквитки и други идентифициращи данни.