HTTP 407 ဒါမှမဟုတ် 401 — ဘယ် login က မအောင်မြင်တာလဲ
Proxy နှင့် ဝက်ဘ်ဆိုက် အထောက်အထားစစ်ဆေးမှုကို ခွဲခြားပြီး မှန်သည့် header များကိုကြည့်ကာ မှားသည့်ဘက်သို့ login အချက်အလက် မပို့ပါနှင့်။
407 က proxy တွင် အထောက်အထားစစ်ဆေးရန် တောင်းဆိုသည်။ 401 က ဦးတည်ရာ resource အတွက် တောင်းဆိုသည်။ Request တစ်ခုက နှစ်မျိုးစလုံးကို တွေ့နိုင်သဖြင့် password မပေးမီ မည်သူတောင်းသလဲ သိပါ။
Status နှင့် authentication challenge header များကို နှိုင်းယှဉ်ပါ
| Response | Challenge header | Login အချက်အလက် header | သက်ဆိုင်သည့်ဘက် |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | ကြားခံ proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | မူရင်း resource ၏ authentication လုပ်ငန်းစဉ် |
Status သည် ပထမဆုံးအရေးကြီးသဲလွန်စဖြစ်သော်လည်း အပြန်အလှန်ဆက်သွယ်မှုတစ်ခုလုံး ကြည့်ပါ။ စာမျက်နှာစာသားတွင် 407 ရေးထားခြင်းသည် တကယ့် HTTP 407 response မဟုတ်ပါ။ သီးသန့် login page ကလည်း 200 ပြန်ပို့ပြီး application layer တွင် အထောက်အထားစစ်ဆေးရန် ဆက်တောင်းနိုင်သည်။
HTTPS က ဝက်ဘ်ဆိုက်မရောက်မီ 407 ဖြင့် ဘာကြောင့် မအောင်မြင်နိုင်သလဲ
ပုံမှန် HTTP proxy ဖြင့် HTTPS request ပို့ရာတွင် client က အများအားဖြင့် CONNECT tunnel ကို ဦးစွာတောင်းသည်။ Proxy က ထို CONNECT request အတွက် authentication တောင်းနိုင်သည်။ မပြီးပါက tunnel မှတစ်ဆင့် ဦးတည်ရာ TLS session မတည်ဆောက်ရသေးပါ။ ထို့ကြောင့် website API token ပြောင်းခြင်းက ဤအဆင့်ကို ပြင်ပေးရန် မဖြစ်နိုင်ချေများသည်။
Challenge ပေါ်သည့်နေရာကို အသေးစိတ် output ဖြင့်ကြည့်ပါ။
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Local listener ကို ကိုယ်ပိုင်တစ်ခုဖြင့် အစားထိုးပြီး log ထဲက ပထမဆုံး challenge ကို ဖတ်ပါ။ CONNECT အတွင်း 407 က destination TLS ထက်စောသည်။ နောက်မှ 401 က tunnel အောင်မြင်ပြီးနောက် ဖြစ်နိုင်သည်။
Proxy အချက်အလက်ကို proxy interface မှပေးပါ
ယုံကြည်ရသည့် administrator ပေးသော endpoint နှင့် account အတွက် curl က authentication scheme ကို ညှိနှိုင်းပြီး မပေးထားသည့် password ကို မေးနိုင်သည်။
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/နမူနာ endpoint နှင့် user ကို သင်အသုံးပြုခွင့်ရှိသော service အချက်အလက်ဖြင့် အစားထိုးပါ။ User တစ်ခုတည်းပေးလျှင် အပေါ်က command တွင် password တိုက်ရိုက်မပါစေပါ။ ပံ့ပိုးသောနည်းများသည် curl build နှင့် proxy အလိုက်ကွာနိုင်သဖြင့် negotiation မအောင်မြင်လျှင် တကယ့် challenge နှင့် build စွမ်းဆောင်ရည်ကို စစ်ပါ။
Proxy authentication option သည် curl ၏ origin-user authentication option နှင့် သီးခြားဖြစ်သည်။ Proxy challenge ကို ဖြေသည့်အစား origin အတွက် Authorization header မထည့်ပါနှင့်။ Proxy login header ကို မသက်ဆိုင်သည့် request များသို့ ကိုယ်တိုင်မလွှဲပါနှင့်၊ app တစ်ခုလုံးပြန်သုံးသော header များတွင်လည်း မသိမ်းပါနှင့်။
Proxy က 407 ဆက်ပို့နေလျှင်
- ရည်ရွယ်ထားသည့် proxy host နှင့် port ကို သုံးကြောင်း အတည်ပြုပါ။
- Basic ဟု မယူဆဘဲ proxy ကြေညာသော scheme များကိုကြည့်ပါ။
- Account အခြေအနေနှင့် service လိုအပ်သော username ပုံစံကို စစ်ပါ။
- အချက်အလက် URL ထဲတွင်ရှိလျှင် special character ပို့သည့်ပုံစံကိုကြည့်ပါ။
- Browser-integrated enterprise authentication အတွက် runtime သို့မဟုတ် platform ပံ့ပိုးမှုလိုသလား စစ်ပါ။
- Client အထောက်အထားမလုံလောက်လျှင် administrator ထံမှ လျှို့ဝှက်အချက်အလက် ဖယ်ထားသော request identifier သို့မဟုတ် server log entry တောင်းပါ။
Login အောင်မြင်ပြီးနောက်လည်း 403 သို့မဟုတ် denied CONNECT သည် access policy ဆုံးဖြတ်ချက်ဖြစ်နိုင်သည်။ Password ထပ်စမ်းခြင်းက တားမြစ်ထားသည့် ဦးတည်ရာဝင်ခွင့် မပေးပါ။
Destination HTTPS က proxy login အချက်အလက်လဲလှယ်မှုတိုင်းကို မကာကွယ်ပါ
Proxy authentication သည် destination TLS မဖြစ်မီ ဖြစ်နိုင်သည်။ Proxy ကိုယ်တိုင်ဆီက ချိတ်ဆက်မှု စာဝှက်မထားဘဲ နည်းလမ်းက ထိုလမ်းကြောင်းတွင် ပြန်သုံးနိုင်သည့် အချက်အလက်ကို ဖော်ပြပါက HTTPS target က ယခင်အပြန်အလှန်ဆက်သွယ်မှုကို နောက်မှ မကာကွယ်နိုင်ပါ။ Service နှင့်ကိုက်ညီသော transport နှင့် authentication ကိုရွေးပါ။ မသိသော public proxy ဆီ private account မပို့ပါနှင့်။
အသေးစိတ် log များကို မျှဝေမီစစ်ပါ။ Tool က ပုံမှန် login field များကိုဖုံးထားလည်း username၊ internal endpoint name၊ cookie သို့မဟုတ် ခွဲခြားသိနိုင်သည့် အချက်အလက် အခြားမျိုးများ ကျန်နိုင်သည်။