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 же башка таануучу маалымат калышы мүмкүн.