Аўтарызацыя прамога проксі ў Apache: Require і AuthMerging
Прасочвайце глабальную і віртуальную проксі-аўтарызацыю праз правілы аб'яднання секцый Apache, а не разглядайце proxy.conf як асобны ўзровень палітыкі.
Правіла ў proxy.conf — не асобы клас правілаў. Apache чытае ўключаную канфігурацыю ў сваё дрэва канфігурацыі; ахопліваючая глабальная секцыя, VirtualHost або адпаведная секцыя вызначае, як дырэктыва ўдзельнічае.
Пачніце з listener і віртуальнага хоста, якія абслугоўваюць запыт прамога проксі. Затым сабярыце адпаведныя секцыі Proxy з гэтага кантэксту і асноўнай канфігурацыі. Важны парадак апрацоўкі секцый, а не толькі тое, які файл быў зменены апошнім.
Аўтарызацыя не заўсёды сумуецца
Пры стандартных паводзінах AuthMerging Off аўтарызацыя наследуецца, пакуль пазнейшая прыдатная секцыя не прадаставіць сваю логіку аўтарызацыі. Гэтая новая логіка можа замяніць папярэднія патрабаванні, а не дадаць яшчэ адно абмежаванне.
| Налада | Спалучэнне з найбліжэйшай папярэдняй секцыяй аўтарызацыі |
|---|---|
| Off | Новая аўтарызацыя можа перавызначыць унаследаваную логіку |
| And | Абодва наборы павінны даць аўтарызацыю |
| Or | Любы з набораў можа даць аўтарызацыю |
Сам AuthMerging лакальны для секцыі, якая яго змяшчае. Не думайце, што аднаразовае ўключэнне And зменіць кожную наступную секцыю.
Трымайце мэтавую палітыку па магчымасці яўнай. Два радкі Require без ахопліваючага кантэйнера аўтарызацыі неяўна з'яўляюцца альтэрнатывамі, таму правіла IP плюс valid-user не азначае аўтаматычна «IP і карыстальнік». Выкарыстоўвайце RequireAll, калі абодва ўмовы належаць аднаму рашэнню.
Перагледзьце поўную адпаведную канфігурацыю, перш чым змяніць уліковы запіс проксі або адкрыць доступ. Затым праверце дазволеныя і забароненыя выпадкі на працуючым listener. Запыт можа быць адхілены—або нечакана дазволены—таму што іншая секцыя забяспечыла эфектыўную аўтарызацыю.