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 anonyme

+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

Ce n’est pas bon car RemoteIPHeader prend la valeur d’entrée et non la variable de sortie. Je fouille actuellement du côté de SetEnv.

J’ai tenté plein d’autres choses et rien. :( rpf, modheader,setenv… Quelqu’un a une autre solution ?

+0 -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 anonyme

+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 anonyme

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

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