Emacs 31.1 တွင် URL proxy လော့ဂ်အင်: auth-source နှင့် CONNECT ကန့်သတ်ချက်များ
Emacs ၏ URL စာကြည့်တိုက်အတွက် စစ်မှန်ကြောင်းအထောက်အထားပြရသော HTTP proxy ကို ပြင်ဆင်ပါ၊ ၎င်း၏ Basic အထောက်အထား ရှာဖွေမှုကို နားလည်ပါ၊ Emacs 31.1 ရှိ HTTPS CONNECT လမ်းကြောင်းကို ထည့်သွင်းစဉ်းစားပါ။
Proxy ၏ လိပ်စာသည် Emacs ကို ဘယ်နေရာတွင် ချိတ်ဆက်ရမည်ကို ပြောပြသည်။ ၎င်း၏ လော့ဂ်အင်သည် စကားပြောဆိုမှု၏ အခြားအပိုင်းဖြစ်သည်။ သာမန် HTTP တောင်းဆိုမှုအတွက် Emacs ၏ URL စာကြည့်တိုက်သည် proxy ၏ စစ်မှန်ကြောင်းအထောက်အထား စိန်ခေါ်မှုကို ဖြေကြားနိုင်သည်၊ auth-source မှ အထောက်အထားများ ရယူနိုင်သည် သို့မဟုတ် အပြန်အလှန် မေးနိုင်သည်၊ ပြီးလျှင် စက်ရှင်တွင် ထားရှိထားသော အထောက်အထားများကို ပြန်လည် အသုံးပြုနိုင်သည်။
အောက်ပါ အသေးစိတ်များသည် Emacs 31.1 ကို လိုက်နာသည်။ ၎င်းတို့သည် URL စာကြည့်တိုက်ကို အသုံးပြုသော လုပ်ဆောင်ချက်များနှင့် သက်ဆိုင်သည်၊ Emacs ပက်ကေ့ချ်မှ စတင်သော ပြင်ပ ဒေါင်းလုဒ်ဆွဲကိရိယာတွင် ၎င်း၏ ကိုယ်ပိုင် စစ်မှန်ကြောင်းအထောက်အထားပြသည့် လမ်းကြောင်း ရှိသည်။
လမ်းကြောင်းကို သတ်မှတ်ပါ၊ ထို့နောက် HTTP ကို လော့ဂ်အင် တောင်းခွင့်ပြုပါ
ပုံသေ proxy အဆုံးမှတ်ကို မှတ်တမ်းတင်ထားသော ရွေးချယ်မှုဖြင့် ရွေးနိုင်သည်:
(setq url-proxy-services
'(("http" . "proxy.example:8080")
("https" . "proxy.example:8080")))
နေရာလွတ်ကို ပေးထားသော အဆုံးမှတ်ဖြင့် အစားထိုးပါ။ သော့များသည် ခရီးဆုံး URL အစီအစဉ်များကို ဖော်ပြသည်။ HTTPS အပိုင်းကို ထည့်ခြင်းသည် HTTPS ခရီးဆုံးများအတွက် လမ်းကြောင်း ရွေးသည်၊ ၎င်းကိုယ်တိုင် အထောက်အထား မပေးပါ။
သာမန် HTTP တောင်းဆိုမှုအတွင်း proxy သည် 407 Proxy Authentication Required နှင့် Proxy-Authenticate စိန်ခေါ်မှုဖြင့် ဖြေကြားနိုင်သည်။ URL စာကြည့်တိုက်သည် ပံ့ပိုးထားသော စစ်မှန်ကြောင်းအထောက်အထားပြ အစီအစဉ်ကို ရွေးပြီး proxy အဆုံးမှတ်အတွက် အထောက်အထားများ ရယူသည်။ ထို့နောက် Proxy-Authorization ဖြင့် ထပ်မံ ကြိုးစားသည်။
Basic စစ်မှန်ကြောင်းအထောက်အထားပြမှုအတွက် သင့်လျော်သော အထောက်အထား မရှိပါက အပြန်အလှန် တောင်းဆိုမှုသည် အသုံးပြုသူအမည်နှင့် စကားဝှက်ကို မေးနိုင်သည်။ အပြန်အလှန်မဟုတ်ဟု အမှတ်အသားပြုထားသော တောင်းဆိုမှုသည် ထို မေးခွန်းများကို မမှီခိုနိုင်ပါ။ Proxy လော့ဂ်အင်သည် ခရီးဆုံး ဝဘ်ဆိုက်၏ လော့ဂ်အင်နှင့်လည်း သီးခြားဖြစ်သည်: ဝဘ်ဆိုက်၏ 401 စိန်ခေါ်မှုသည် အခြားလမ်းကြောင်းကို လိုက်နာသည်။
ရေရှည်အထောက်အထားများကို auth-source တွင် ထားပါ
auth-source သည် ~/.authinfo.gpg ကဲ့သို့ ကုဒ်ဝှက်ထားသော အထောက်အထားဖိုင်ကို ဖတ်ပြီးဖြစ်ပါက ဤဥပမာအတွက် Basic အပိုင်းသည် အောက်ပါပုံစံ ရှိသည်:
machine proxy.example port http login YOUR_LOGIN password YOUR_PASSWORD
သင့် စစ်မှန်သော အကောင့်နှင့် လျှို့ဝှက်ချက်ကို အသုံးပြုပါ၊ ပြီးလျှင် ဖိုင်သည် သင်ပြင်ဆင်ထားသော auth-sources ထဲတွင် ပါဝင်ကြောင်း သေချာပါစေ။ ထိုစာကြောင်းသည် ကိုက်ညီသော အကွက်များကို သရုပ်ပြသည်၊ သင့် Lisp စတင်ဖိုင်တွင် စကားဝှက် ထည့်ရန် ညွှန်ကြားချက် မဟုတ်ပါ။
Emacs 31.1 ၏ Basic အကောင်အထည်ဖော်မှုတွင် အသေးစိတ် နှစ်ခု အရေးကြီးသည်။ ၎င်းသည် proxy ၏ လက်ခံအမည်ကို ဂဏန်း TCP ပေါက်ပေါက်မပါဘဲ ရှာဖွေပြီး proxy URL ၏ အစီအစဉ်ကို auth-source ၏ ပေါက်တန်ဖိုးအဖြစ် ပေးပို့သည်။ ဤ HTTP proxy အတွက် TCP ချိတ်ဆက်မှုသည် ပေါက် 8080 ကို အသုံးပြုသော်လည်း ထိုတန်ဖိုးမှာ http ဖြစ်သည်။
ဤ ရှာဖွေမှုတွင် စိန်ခေါ်မှု၏ realm သို့မဟုတ် ဂဏန်း proxy ပေါက်ပေါက် မပါဝင်ပါ။ တူညီသော လက်ခံအမည်ပေါ်ရှိ realm များ သို့မဟုတ် proxy ပေါက်များစွာအတွက် မတူညီသော Basic စကားဝှက်များကို ရွေးလိမ့်မည်ဟု မမျှော်လင့်ပါနှင့်။ Digest သည် အခြား လက်ခံရှာဖွေမှုကို အသုံးပြုသည်၊ ထို့ကြောင့် အထက်ပါ ဥပမာသည် Basic အတွက် အထူးဖြစ်သည်။
URL စာကြည့်တိုက်သည် ၎င်း၏ ကိုယ်ပိုင် စစ်မှန်ကြောင်းအထောက်အထားပြ cache ကိုလည်း ထိန်းသိမ်းသည်။ ၎င်း၏ Basic အပိုင်းများသည် proxy အဆုံးမှတ်များကို ခွဲခြားပြီး အဆုံးမှတ်တစ်ခုအတွင်း realm သို့မဟုတ် ဖိုလ်ဒါ ကိုက်ညီမှုကို အသုံးပြုသည်၊ ထို cache သည် auth-source ရှာဖွေမှုနှင့် သီးခြားဖြစ်သည်။ မေးခွန်းတွင် စကားဝှက် ရိုက်ထည့်ခြင်းသည် သင့် ရေရှည်အထောက်အထားဖိုင်တွင် အပိုင်းအသစ် မသိမ်းဆည်းဘဲ စက်ရှင် cache ကို ဖြည့်နိုင်သည်။
HTTPS တွင် စောသော စစ်မှန်ကြောင်းအထောက်အထားပြခြင်း အဆင့် ရှိသည်
HTTP proxy မှတစ်ဆင့် HTTPS ခရီးဆုံးအတွက် Emacs သည် CONNECT ကို ဦးစွာ ပို့သည်။ ထို့ကြောင့် ဝဘ်ဆိုက်နှင့် ကုဒ်ဝှက်ထားသော ချိတ်ဆက်မှုသို့ မရောက်မီ စစ်မှန်ကြောင်းအထောက်အထားပြရန် လိုအပ်နိုင်သည်။
Emacs 31.1 တွင် CONNECT တောင်းဆိုမှု တည်ဆောက်သူသည် ၎င်း၏ စစ်မှန်ကြောင်းအထောက်အထားပြ ယန္တရားမှတစ်ဆင့် ရှိပြီးသား အထောက်အထားကို စစ်ဆေးသည်၊ cache လုပ်ထားသော Basic အထောက်အထားများ အပါအဝင်။ ၎င်း၏ Basic လမ်းကြောင်းသည် ထိုအချိန်တွင် auth-source အပိုင်းအသစ်ကို မမေးပါ၊ မဆွဲယူပါ။ 200 မဟုတ်သော CONNECT တုံ့ပြန်မှုသည်လည်း အထက်တွင် ဖော်ပြထားသော သာမန် HTTP 407 စိန်ခေါ်မှု ကိုင်တွယ်သူထဲ မဝင်ပါ။
ထို့ကြောင့် သာမန် HTTP Basic စိန်ခေါ်မှုကို ဖြေကြားနိုင်သော auth-source အပိုင်းသည် စက်ရှင်အသစ်၏ ပထမ HTTPS တောင်းဆိုမှု အောင်မြင်စွာ စစ်မှန်ကြောင်းအထောက်အထားပြလိမ့်မည်ဟု အာမမခံနိုင်ပါ။ သင့်လျော်သော cache အထောက်အထားများ ရှိသော စက်ရှင်သည် မတူညီသော စတင်အခြေအနေ ရှိသည်။ တူညီသော စကားဝှက် အပိုင်းကို ထပ်ခါတလဲလဲ တည်းဖြတ်ခြင်းသည် လမ်းကြောင်း နှစ်ခုအကြား ဤကွာဟမှုကို ၎င်းကိုယ်တိုင် မဖယ်ရှားနိုင်ပါ။
HTTPS လုပ်ဆောင်ချက်သည် proxy တွင် ရပ်တန့်ပါက CONNECT သည် 407 ရရှိခဲ့ခြင်း ရှိ/မရှိ နှင့် ဤထုတ်ဝေမှု၏ အပြုအမူကို အသုံးပြုနေခြင်း ရှိ/မရှိ ကို ဆုံးဖြတ်ပါ။ proxy က ကမ်းလှမ်းသော စစ်မှန်ကြောင်းအထောက်အထားပြ အစီအစဉ်ကိုလည်း အတည်ပြုပါ။ Basic အထောက်အထား အပိုင်းသည် လုပ်ငန်း စစ်မှန်ကြောင်းအထောက်အထားပြ စနစ်တိုင်းအတွက် ကမ္ဘာလုံးဆိုင်ရာ အဒက်တာ မဟုတ်ပါ။
ရေရှည်ဖွဲ့စည်းမှုကို အများသူငှာ proxy ရွေးချယ်မှုတွင်လည်းကောင်း သင်ရွေးချယ်ထားသော အထောက်အထား backend တွင်လည်းကောင်း ထားရှိပါ။ URL စာကြည့်တိုက်၏ အတွင်းပိုင်း Basic သိုလှောင်ရုံသည် ဤအပြုအမူကို နားလည်ရန် အသုံးဝင်သည်၊ သို့သော် ထို ကိုယ်ပိုင် ဒေတာဖွဲ့စည်းပုံကို လက်ဖြင့် ဖြည့်ခြင်းသည် ပြင်ဆင်မှုကို အကောင်အထည်ဖော်မှု အသေးစိတ်များနှင့် ချိတ်ဆက်သွားမည်။