Django (zds-site) et Apache2 avec un virtualhost

Utilisateur avec leur vrai IP en : remote_addr

L’auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour,

J’utilise Apache2 comme firewall applicatif pour Django cependant tous les utilisateurs on la REMOTE_ADDR égale à 127.0.0.1, ce qui ne me convient pas.

<VirtualHost *:80>
    ServerName vps.a312.fr

    ProxyPass / http://localhost:8080/
    ProxyPassReverse / http://vps.a312.fr/

    RemoteIPHeader X-Forwarded-For

    ErrorLog ${APACHE_LOG_DIR}/zdsenv_error.log
    CustomLog ${APACHE_LOG_DIR}/zdsenv_access.log combined
</VirtualHost>

J’ai ajouté : RemoteIPHeader X-Forwarded-For mais l’ip ne change pas quand je regarde dans les debugs du zds, c’est-à-dire le volet à droite :

En-têtes de requête
X-Forwarded-For 45.x.x.x

Environnement WSGI
REMOTE_ADDR 127.0.0.1

J’ai relancé apache et activé mod_remoteip mais aucun changement. Avez-vous une piste ?

Bon vol,

A-312.

Édité par A-312

✈️ // 🐺 Ami des loups // 🎮 Coding Game // 🐤 Twitter @A312_zds // :B // L’hiver vient // @**A-312** pour me ping

+0 -0

Équipe technique

En prod on utilise le header X-Real-IP, cf. le code ici: https://github.com/zestedesavoir/zds-site/blob/4ee284feae9aed24118312291954ff5402a53c59/zds/member/views.py#L1192-L1193

--- a   2018-08-28 09:57:31.000000000 +0200
+++ b   2018-08-28 09:57:21.000000000 +0200
@@ -1,11 +1,11 @@
 <VirtualHost *:80>
     ServerName vps.a312.fr

     ProxyPass / http://localhost:8080/
     ProxyPassReverse / http://vps.a312.fr/

-    RemoteIPHeader X-Forwarded-For
+    RemoteIPHeader X-Real-IP

     ErrorLog ${APACHE_LOG_DIR}/zdsenv_error.log
     CustomLog ${APACHE_LOG_DIR}/zdsenv_access.log combined
 </VirtualHost>

"I also don’t trust Caribou anymore." —  Joss Whedon

+1 -0
Auteur du sujet

Petit explication au passage :

On utilise le module Rewrite et Headers d’apache.

On utilise Rewrite pour définir une variable d’environnement Zds-Real-IP contenant l’ip du client car RequestHeader supporte uniquement les variables d’environnements.

Puis RequestHeader s’active seulement si env=Zds-Real-Ip est défini [donc dans tous les cas], on définit HTTP_ZDS_REAL_IP par notre variable d’environnement Zds-Real-Ip soit notre IP.


La condition est inutile mais dans le cas d’un imprévu, il vaut mieux que HTTP_ZDS_REAL_IP ne soit pas déclaré à null pour éviter que le zds-site (django) se mange une erreur python. Ceci revient à l’usage "par défaut" mais on autorise le client à modifier son HEADER et donc la valeur de ZDS_REAL_IP, ce qui ne peut pas arriver car l’URL rewrite s’active à tous les coups.

Édité par A-312

✈️ // 🐺 Ami des loups // 🎮 Coding Game // 🐤 Twitter @A312_zds // :B // L’hiver vient // @**A-312** pour me ping

+0 -0
Auteur du sujet

Question : pourquoi utiliser un truc lourd comme apache et un truc puissant comme wsgi au lieu d’un truc simple à configurer et léger comme nginx et le serveur de dev de Django ?

cepus

Au début pour faire un firewall/proxy applicatif, je pensais à utiliser nginx. Mais vu que je suis plus habitué à utiliser un environnement apache2 et que je ne m’attends pas à avoir un trafic qui demande à opti ma connexion ou plutôt mes ressources systèmes, j’ai choisi apache2 pour un gain de temps et ne pas perdre mon temps à lire et comprendre le fonctionnement de nginx (et surtout les mauvaises choses à ne pas faire). Je savais déjà plus où moins à quoi devait ressembler mon fichier virtualhost.

et un truc puissant comme wsgi

Je n’ai pas compris ce qu’était un wsgi, c’est ce que j’appelle moi un "firewall/proxy applicatif" ?

Édité par A-312

✈️ // 🐺 Ami des loups // 🎮 Coding Game // 🐤 Twitter @A312_zds // :B // L’hiver vient // @**A-312** pour me ping

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte