إلزام Apache بعنوان IP للعميل وتسجيل دخول الوكيل معًا
اجمع بين مصادقة وكيل Apache 2.4 وقيود عنوان العميل من دون أن يمنح أي شرط منفرد الوصول وحده.
عندما يجب على وكيل إعادة التوجيه في Apache 2.4 طلب عنوان مصدر معتمد وتسجيل دخول صالح معًا، استخدم <RequireAll>:
<Proxy "*">
AuthType Basic
AuthName "Private proxy"
AuthBasicProvider file
AuthUserFile /etc/apache2/private-proxy-users
<RequireAll>
Require ip 192.0.2.25
Require valid-user
</RequireAll>
</Proxy>ادمج مقطع التفويض هذا في الوكيل المقيّد الموجود. استبدل عنوان العميل ومسار ملف الحسابات؛ يجب أن تكون وحدات المصادقة والتفويض متاحة، وأن يحتوي الملف مسبقًا على المستخدمين المقصودين. ليس هذا نشرًا كاملًا للمستمع.
هناك تفصيلان يحددان السياسة. تعبّر الحاوية عن AND؛ ولا يعني وضع المتطلبات الإيجابية جنبًا إلى جنب بالضرورة وجوب استيفائها كلها. يقبل Require valid-user حسابًا موثّقًا، بينما يسمّي Require user alice حسابًا واحدًا. لا يعبّر Require user المجرد عن شيء. راجع مرجع Apache لتفويض المستخدمين.
| المصدر | تسجيل الدخول | النتيجة المطلوبة |
|---|---|---|
| مسموح | صالح | يُسمح بالطلب المصرّح به المقصود. |
| مسموح | مفقود أو غير صالح | لا يوجد تمرير مصرّح به. |
| خارج المصدر المسموح | صالح | لا يوجد تمرير مصرّح به. |
راجع المضيف الافتراضي المحيط والأقسام الأخرى المطابقة للتفويض قبل الاعتماد على المقطع، ثم @@اختبر حد التفويض؛ يمكن لإعداد أكثر تحديدًا أن يغيّر النتيجة الفعلية. يحتاج تسجيل دخول Basic أيضًا إلى نقل محمي بين العميل والوكيل. يبدأ HTTPS للوجهة لاحقًا ولا يحمي تبادل بيانات الاعتماد السابق بنص واضح.