curl တွင် NTLM proxy login ပြဿနာ ရှာဖွေခြင်း
NTLM proxy က login ငြင်းပယ်လျှင် curl build ၏ ပံ့ပိုးမှု၊ proxy ၏ authentication challenge နှင့် ချိတ်ဆက်မှုဆက်လက်တည်ရှိခြင်းကို စစ်ဆေးပါ။
NTLM proxy authentication တွင် handshake ပါဝင်သည်။ အသုံးပြုသူအမည်ကို တစ်ကြိမ်တွဲပေးရုံသာ မဟုတ်ပါ။ အကောင့်စကားဝှက်ကို မပြောင်းမီ proxy က NTLM ကို အမှန်တကယ်ပေးကြောင်း နှင့် curl executable က ပံ့ပိုးကြောင်း အတည်ပြုပါ။
curl --version
သင့် request ကို အလုပ်လုပ်ပေးသော executable ၏ feature list ကို စစ်ဆေးပါ။ အခြား curl တပ်ဆင်မှု၊ container image သို့မဟုတ် operating-system build တွင် authentication ပံ့ပိုးမှု ကွဲပြားနိုင်သည်။
proxy အတွက် သီးသန့် authentication နည်းလမ်းရွေးပါ
curl --proxy http://proxy.example:3128 --proxy-ntlm --proxy-user 'EXAMPLE\alice' --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/
endpoint၊ domain နှင့် အသုံးပြုသူအမည်တို့သည် ဥပမာများဖြစ်သည်။ administrator ပေးထားသော ပုံစံကို သုံးပါ။ argument ထဲတွင် စကားဝှက်မပါလျှင် ပြသထားသော command တွင် လျှို့ဝှက်ချက်ကျန်မည့်အစား curl က ထည့်ရန်မေးနိုင်သည်။
ပထမ authentication challenge သည် ညှိနှိုင်းမှု၏ အစိတ်အပိုင်းဖြစ်နိုင်သည်။ ပြီးဆုံးသွားသော handshake နောက်မှ ငြင်းပယ်ခြင်းနှင့် ခွဲခြားပါ။ proxy challenge ကိုဖြေရန် မူရင်း server အတွက် NTLM option မသုံးပါနှင့်။
စစ်ဆေးမှုထဲတွင် ချိတ်ဆက်မှုအပြုအမူပါ ထည့်ပါ
NTLM state သည် ချိတ်ဆက်မှုနှင့် ချိတ်ဆက်နေသည်။ handshake သည် မျှော်မှန်းထားသော connection path မှ ဆက်လက်ဆောင်ရွက်ရမည်။ အဆင့်များကြား ချိတ်ဆက်မှုကို ထပ်ခါထပ်ခါ အစားထိုးလျှင် ပြီးစီးမှုကို တားဆီးနိုင်သည်။
Libcurl သုံးသော application တွင် authentication နှင့် connection reuse ကို library က စီမံခန့်ခွဲစေပါ။ မတူညီသော identity များအတွက် authenticate လုပ်ပြီးသော ချိတ်ဆက်မှုများကို အပြန်အလှန်အစားထိုးနိုင်သည်ဟု ယူဆသည့် အထွေထွေ pool မတည်ဆောက်ပါနှင့်။ အဆင့်များစွာ သို့မဟုတ် ကြားခံ service တွင် လိုအပ်သော ချိတ်ဆက်မှုအစီအစဉ်ကို ထိန်းသိမ်းထားသလား စစ်ဆေးပါ။
ပံ့ပိုးမှုနှင့် နည်းလမ်းရွေးချယ်မှု မှန်လျှင် အကောင့်ပုံစံ၊ domain policy နှင့် အရေးကြီးအချက်အလက် ဖယ်ထားသော server authentication log များကို စုံစမ်းပါ။ challenge တစ်ခုခု မရောက်မီ timeout ဖြစ်ခြင်းသည် ရောက်ရှိနိုင်မှု ပြဿနာပင်ဖြစ်ပြီး NTLM စကားဝှက်မှားကြောင်း သက်သေမဟုတ်ပါ။
အသေးစိတ် trace များတွင် authentication token နှင့် အတွင်းပိုင်းအမည်များ ပါနိုင်သည်။ ၎င်းတို့ကို စက်တွင်းတွင် သုံးပြီး မျှဝေမီ အရေးကြီးအချက်အလက် ဖယ်ပါ။ အများမြင် error report တွင် token အစိမ်းဖလှယ်မှုကို မလိုအပ်ပါ။