HTTP 407 чи 401: яка автентифікація не працює?
Відрізняйте автентифікацію на проксі від входу на сайт, перевіряйте потрібні заголовки та не надсилайте облікові дані не тому вузлу.
407 вимагає автентифікації на проксі. 401 вимагає її для цільового ресурсу. Один запит може зустріти обидва коди, тому перед передаванням пароля з’ясуйте, хто його просить.
Порівняйте статус і заголовки запиту автентифікації
| Відповідь | Заголовок запиту автентифікації | Заголовок облікових даних | Учасник |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Проміжний проксі |
| 401 Unauthorized | WWW-Authenticate | Authorization | Процес автентифікації ресурсу джерела |
Статус — важлива перша підказка, але перегляньте весь обмін. Число 407 у тексті сторінки не дорівнює справжній відповіді HTTP 407. Так само власна сторінка входу може повертати 200 і все одно вимагати автентифікації на рівні застосунку.
Чому HTTPS може отримати 407 ще до звернення до сайту
Під час передавання HTTPS через звичайний HTTP-проксі клієнт зазвичай спершу просить створити тунель 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 цілі не захищає попередній обмін заднім числом. Виберіть відповідні сервісу транспорт та автентифікацію; не надсилайте приватні облікові записи невідомому публічному проксі.
Перед поширенням докладних журналів перегляньте їх. Навіть якщо інструмент приховує звичайні поля облікових даних, там можуть лишитися користувачі, внутрішні назви кінцевих точок, cookie чи інші ідентифікаційні дані.