Apache beide de kliïnt-IP en in proxy-oanmelding fereaskje litte
Kombinearje Apache 2.4-proxyautentikaasje mei beheiningen foar it kliïntadres, sûnder dat ien eask op himsels tagong jout.
As in Apache 2.4-forwardproxy sawol it goedkarde boarneadres as in jildige oanmelding fereaskje moat, brûk dan <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>Foegje dit machtigingsfragmint ta oan de besteande beheinde proxy. Ferfang it kliïntadres en it paad nei it akkountbestân; de autentikaasje- en machtigingsmodules moatte beskikber wêze, en it bestân moat de bedoelde brûkers al befetsje. Dit is gjin folsleine ynset fan in listener.
Twa details bepale it belied. De container drukt AND út; positive easken neistinoar pleatse fereasket net needsaaklik allegear. Require valid-user akseptearret in autentisearre akkount, wylst Require user alice ien akkount neamt. In inkeld Require user drukt neat út. Sjoch de Apache-referinsje foar brûkersmachtiging.
| Boarne | Oanmelding | Fereaske útkomst |
|---|---|---|
| Tastien | Jildich | It bedoelde autorisearre fersyk wurdt tastien. |
| Tastien | Untbrekt of ûnjildich | Gjin autorisearre trochstjoering. |
| Bûten de tastiene boarne | Jildich | Gjin autorisearre trochstjoering. |
Besjoch de omlizzende firtuele host en oare oerienkommende machtigingsseksjes foardatst op it fragmint fertroust, en @@test de autorisaasjegrins; mear spesifike konfiguraasje kin it effektive resultaat feroarje. Basic-oanmelding hat ek in beskerme kliïnt-nei-proxy-transport nedich. HTTPS fan it doel begjint letter en beskermet de eardere útwikseling fan net-fersifere oanmeldgegevens net.