Faceți ca Apache să ceară atât IP-ul clientului, cât și autentificarea la proxy
Combină autentificarea proxy Apache 2.4 cu restricții de adresă ale clientului, fără ca o singură condiție să acorde accesul singură.
Când un proxy de redirecționare Apache 2.4 trebuie să ceară atât adresa sursă aprobată, cât și o autentificare validă, folosește <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>Integrează acest fragment de autorizare în proxy-ul restricționat existent. Înlocuiește adresa clientului și calea fișierului cu conturi; modulele de autentificare și autorizare trebuie să fie disponibile, iar fișierul trebuie să conțină deja utilizatorii vizați. Nu este o implementare completă a ascultătorului.
Două detalii stabilesc politica. Containerul exprimă AND; așezarea cerințelor pozitive una lângă alta nu le impune neapărat pe toate. Require valid-user acceptă un cont autentificat, iar Require user alice numește un cont. Un Require user singur nu exprimă nimic. Consultă referința Apache despre autorizarea utilizatorilor.
| Sursă | Autentificare | Rezultatul cerut |
|---|---|---|
| Permis | Valid | Cererea autorizată dorită este permisă. |
| Permis | Lipsește sau este invalid | Nicio redirecționare autorizată. |
| În afara sursei permise | Valid | Nicio redirecționare autorizată. |
Examinează gazda virtuală care înconjoară fragmentul și alte secțiuni de autorizare corespunzătoare înainte de a te baza pe el, apoi @@testează limita autorizării; configurația mai specifică poate schimba rezultatul efectiv. Autentificarea Basic necesită și un transport protejat între client și proxy. HTTPS al destinației începe mai târziu și nu protejează schimbul anterior de acreditări în clar.