Apache yo'naltiruvchi proksisi avtorizatsiyasi: Require va AuthMerging
proxy.conf ni alohida siyosat qatlami deb hisoblash o'rniga, Apache bo'limlarini birlashtirish qoidalari orqali global va virtual xost proksi avtorizatsiyasini kuzatib boring.
proxy.conf dagi qoida alohida qoida sinfi emas. Apache kiritilgan konfiguratsiyani o'z konfiguratsiya daraxtiga o'qiydi; o'rab turgan global, VirtualHost yoki mos bo'lim direktivaning qanday ishtirok etishini belgilaydi.
Yo'naltiruvchi proksi so'roviga xizmat qiluvchi tinglovchi va virtual xostdan boshlang. So'ngra shu kontekst va asosiy konfiguratsiyadan mos Proxy bo'limlarini to'plang. Bo'limlarni qayta ishlash tartibi muhim, faqat qaysi fayl oxirgi tahrirlangani emas.
Avtorizatsiya har doim yig'ilmaydi
Standart AuthMerging Off xatti-harakatida avtorizatsiya keyingi qo'llaniladigan bo'lim o'z avtorizatsiya mantig'ini bermaguncha meros bo'lib o'tadi. Bu yangi mantiq yana bir cheklov qo'shish o'rniga oldingi talablarni almashtirishi mumkin.
| Sozlama | Eng yaqin oldingi avtorizatsiya bo'limi bilan birikma |
|---|---|
| Off | Yangi avtorizatsiya meros qolgan mantiqni bekor qilishi mumkin |
| And | Ikkala to'plam ham avtorizatsiya berishi kerak |
| Or | Har qanday to'plam avtorizatsiya berishi mumkin |
AuthMerging o'zi uni o'z ichiga olgan bo'limga xos. And ni bir marta sozlash har bir keyingi bo'limni o'zgartiradi deb o'ylamang.
Imkon qadar mo'ljallangan siyosatni aniq saqlang. O'rab turuvchi avtorizatsiya konteynerisiz ikkita Require qatori bevosita muqobil hisoblanadi, shuning uchun IP qoidasi va valid-user avtomatik ravishda «IP va foydalanuvchi» emas. Foydalaning ikkala shart bitta qarorga tegishli bo'lganda RequireAll.
Proksi hisobini o'zgartirish yoki kirishni ochishdan oldin to'liq mos konfiguratsiyani ko'rib chiqing. So'ngra ishlab turgan tinglovchiga qarshi ruxsat etilgan va rad etilgan holatlarni sinab ko'ring. So'rov rad etilishi—yoki kutilmaganda ruxsat etilishi—mumkin, chunki samarali avtorizatsiyani boshqa bo'lim bergan.