proxy.conf ထဲရှိ စည်းမျဉ်းသည် အထူးစည်းမျဉ်းအမျိုးအစား မဟုတ်ပါ။ Apache သည် ထည့်သွင်းထားသော ဖွဲ့စည်းမှုကို ၎င်း၏ ဖွဲ့စည်းမှုသစ်ပင်ထဲသို့ ဖတ်သည်။ ဝန်းရံထားသော ကမ္ဘာလုံးဆိုင်ရာ၊ VirtualHost သို့မဟုတ် ကိုက်ညီသော ကဏ္ဍက ညွှန်ကြားချက် မည်သို့ပါဝင်သည်ကို ဆုံးဖြတ်သည်။

ရှေ့ဆက် proxy တောင်းဆိုချက်ကို ဝန်ဆောင်နေသော listener နှင့် ဗားချူအယ်လ်ဟိုစ့်မှ စတင်ပါ။ ထို့နောက် ထိုအကြောင်းအရာနှင့် ပင်မဖွဲ့စည်းမှုမှ ကိုက်ညီသော Proxy ကဏ္ဍများကို စုဆောင်းပါ။ ကဏ္ဍများ လုပ်ဆောင်သည့် အစီအစဉ်သည် အရေးကြီးသည်၊ မည်သည့်ဖိုင်ကို နောက်ဆုံးတည်းဖြတ်ခဲ့သည်သာ မဟုတ်ပါ။

ခွင့်ပြုချက်သည် အမြဲစုပုံမနေပါ

မူလ AuthMerging Off အပြုအမူဖြင့် နောက်ပိုင်း သက်ဆိုင်သော ကဏ္ဍတစ်ခုက ၎င်း၏ ကိုယ်ပိုင် ခွင့်ပြုချက်ဆိုင်ရာ ယုတ္တိကို မပေးမချင်း ခွင့်ပြုချက်ကို အမွေဆက်ခံသည်။ ထိုယုတ္တိအသစ်သည် နောက်ထပ် ကန့်သတ်ချက်တစ်ခု ထပ်ထည့်မည့်အစား ယခင်လိုအပ်ချက်များကို အစားထိုးနိုင်သည်။

ဆက်တင်အနီးစပ်ဆုံး ယခင် ခွင့်ပြုချက်ကဏ္ဍနှင့် ပေါင်းစပ်မှု
Offခွင့်ပြုချက်အသစ်သည် အမွေဆက်ခံထားသော ယုတ္တိကို ကျော်လွှားနိုင်သည်
Andအစုနှစ်ခုစလုံး ခွင့်ပြုရမည်
Orမည်သည့်အစုမဆို ခွင့်ပြုနိုင်သည်

AuthMerging ကိုယ်တိုင်သည် ၎င်းပါဝင်သော ကဏ္ဍအတွက်သာ ဒေသတွင်းဖြစ်သည်။ And ကို တစ်ကြိမ်သတ်မှတ်လိုက်ရုံဖြင့် နောက်ပိုင်းကဏ္ဍတိုင်း ပြောင်းလဲမည်ဟု မယူဆပါနှင့်။

ဖြစ်နိုင်သမျှ ရည်ရွယ်ထားသော မူဝါဒကို ရှင်းလင်းစွာ ထားပါ။ ဝန်းရံထားသော ခွင့်ပြုချက်ကွန်တိန်နာ မရှိသော Require လိုင်းနှစ်ခုသည် သွယ်ဝိုက်၍ အခြားရွေးချယ်စရာများဖြစ်သည်၊ ထို့ကြောင့် IP စည်းမျဉ်းနှင့် valid-user သည် အလိုအလျောက် “IP နှင့် အသုံးပြုသူ” မဟုတ်ပါ။ အသုံးပြုပါ အခြေအနေနှစ်ခုစလုံး တူညီသော ဆုံးဖြတ်ချက်တွင် ပါဝင်သောအခါ RequireAll.

proxy အကောင့်ကို မပြောင်းလဲမီ သို့မဟုတ် ဝင်ရောက်ခွင့်ကို မဖွင့်မီ ကိုက်ညီသော ဖွဲ့စည်းမှု အပြည့်အစုံကို ပြန်လည်သုံးသပ်ပါ။ ထို့နောက် လည်ပတ်နေသော listener ကို ဆန့်ကျင်၍ ခွင့်ပြုထားသော နှင့် ငြင်းပယ်ထားသော ကိစ္စများကို စမ်းသပ်ပါ။ အခြားကဏ္ဍတစ်ခုက ထိရောက်သော ခွင့်ပြုချက်ကို ပေးထားသောကြောင့် တောင်းဆိုချက်ကို ငြင်းပယ်ခံရ—သို့မဟုတ် မမျှော်လင့်ဘဲ ခွင့်ပြုခံရ—နိုင်သည်။

ဆက်စပ်ဆောင်းပါးများ