Ստիպել 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-ը սկսվում է ավելի ուշ և չի պաշտպանում նախորդ պարզ տեքստով հավատարմագրերի փոխանակումը։