Чаму пароль каталога Apache не абараняе прамы праксі
Абароненая старонка прывітання і дазволены запыт прамога праксі выкарыстоўваюць розныя кантэксты канфігурацыі. Размяшчайце палітыку праксі ў канфігурацыі сервера або віртуальнага хоста.
Запыт пароля на галоўнай старонцы Apache абараняе толькі гэты лакальны рэсурс. Ён не даказвае, што адвольныя запыты прамога праксі патрабуюць таго ж уваходу.
.htaccess датычыцца падтрымліванай канфігурацыі каталога; гэта не канчатковы фільтр для кожнага запыту. Раздзелы ProxyRequests і <Proxy> належаць канфігурацыі сервера або віртуальнага хоста. Размяшчайце аўтарызацыю прамога праксі там, выкарыстоўваючы сінтаксіс аўтарызацыі Apache 2.4 і неабходную наладу аўтэнтыфікацыі.
Для прыватнага сэрвісу свядома спалучыце патрабаванні да крыніцы кліента і ўліковага запісу. Затым праверце віртуальны хост, які выбірае кожны слухач, уключаючы прадвызначаныя хасты і атрыманую ў спадчыну канфігурацыю. Доступ да аднаго абароненага імя хоста не даказвае, што іншы актыўны хост мае тыя ж абмежаванні праксі.
ProxyPass выконвае іншую ролю, звычайна супастаўляючы лакальную прастору імёнаў з бэкэндам. Яго даданне не дазваляе адвольныя прамыя прызначэнні.
Калі вы можаце рэдагаваць толькі дакументы аднаго сайта, вам можа не хапаць адміністрацыйных паўнамоцтваў, каб усталяваць мяжу доступу гэтага сэрвісу. Атрымайце змену канфігурацыі сервера або выкарыстайце ўхвалены існуючы праксі; пароль каталога не можа яго замяніць.