Apache ফরওয়ার্ড প্রক্সি অনুমোদন: Require এবং AuthMerging
proxy.conf-কে আলাদা নীতি স্তর হিসেবে না দেখে Apache-এর সেকশন-মার্জিং নিয়মের মাধ্যমে গ্লোবাল ও ভার্চুয়াল-হোস্ট প্রক্সি অনুমোদন অনুসরণ করুন।
proxy.conf-এর একটি নিয়ম কোনো বিশেষ শ্রেণির নিয়ম নয়। Apache অন্তর্ভুক্ত কনফিগারেশন তার কনফিগারেশন ট্রি-তে পড়ে; পরিবেষ্টক গ্লোবাল, VirtualHost বা মিলিত সেকশন নির্ধারণ করে নির্দেশটি কীভাবে অংশ নেয়।
ফরওয়ার্ড-প্রক্সি অনুরোধ পরিবেশনকারী লিসেনার ও ভার্চুয়াল হোস্ট দিয়ে শুরু করুন। তারপর সেই প্রসঙ্গ ও মূল কনফিগারেশন থেকে মিলিত Proxy সেকশনগুলো সংগ্রহ করুন। সেকশন প্রক্রিয়াকরণের ক্রম গুরুত্বপূর্ণ, কেবল কোন ফাইল শেষে সম্পাদনা হয়েছে তা নয়।
অনুমোদন সর্বদা সঞ্চয়ী নয়
ডিফল্ট AuthMerging Off আচরণে, পরবর্তী প্রযোজ্য সেকশন নিজের অনুমোদন লজিক সরবরাহ করার আগ পর্যন্ত অনুমোদন উত্তরাধিকারসূত্রে পাওয়া যায়। সেই নতুন লজিক আরেকটি বিধিনিষেধ যোগ না করে পূর্ববর্তী প্রয়োজনীয়তাগুলো প্রতিস্থাপন করতে পারে।
| সেটিং | নিকটতম পূর্ববর্তী অনুমোদন সেকশনের সঙ্গে সমন্বয় |
|---|---|
| Off | নতুন অনুমোদন উত্তরাধিকৃত লজিক অগ্রাহ্য করতে পারে |
| And | উভয় সেটকেই অনুমোদন দিতে হবে |
| Or | যেকোনো একটি সেট অনুমোদন দিতে পারে |
AuthMerging নিজে যে সেকশনে আছে তার মধ্যেই সীমিত। একবার And সেট করলে পরবর্তী প্রতিটি সেকশন বদলে যাবে বলে ধরে নেবেন না।
যেখানে সম্ভব অভীষ্ট নীতি স্পষ্ট রাখুন। পরিবেষ্টক অনুমোদন ধারক ছাড়া দুটি Require লাইন অন্তর্নিহিতভাবে বিকল্প, তাই IP নিয়মের সঙ্গে valid-user স্বয়ংক্রিয়ভাবে “IP ও ব্যবহারকারী” নয়। ব্যবহার করুন উভয় শর্ত একই সিদ্ধান্তের হলে RequireAll।
প্রক্সি অ্যাকাউন্ট বদলানো বা অ্যাক্সেস খোলার আগে সম্পূর্ণ মিলিত কনফিগারেশন পর্যালোচনা করুন। তারপর চালু লিসেনারের বিরুদ্ধে অনুমোদিত ও প্রত্যাখ্যাত ক্ষেত্রগুলো পরীক্ষা করুন। একটি অনুরোধ প্রত্যাখ্যাত হতে পারে—বা অপ্রত্যাশিতভাবে অনুমোদিত হতে পারে—কারণ অন্য একটি সেকশন কার্যকর অনুমোদন সরবরাহ করেছে।