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/Жергілікті тыңдаушыны өзіңіздікімен ауыстырып, журналдағы алғашқы талапты оқыңыз. CONNECT кезіндегі 407 мақсаттың 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 немесе басқа сәйкестендіру деректері қалуы мүмкін.