Comment déclencher django DEBUG sur un serveur de production de manière non intrusive

Question

Je recherche une méthode sûre pour déclencher DEBUG pour les requêtes INTERNAL_IPS sur un serveur de production django sans nécessiter la modification d'un fichier settings.py. Principalement pour faire en sorte que la barre d'outils de certains concepteurs vérifie les problèmes sur les données/médias en direct, mais sans compter sur eux pour réinitialiser les paramètres une fois qu'ils ont terminé.

Semblable à cette méthode. Cependant, cela ne convient qu'au déploiement.

http://nicksergeant.com/blog/django/automatically-setting-debug-your-django-app-based-server-hostname

dans le passé sur les systèmes à base de php que j'ai eu mydomain.com et une démo mydomaincom.myprodserver.com où le domaine prodserver peut exécuter automatiquement le code de débogage basé sur $ _SERVER [ « HOST_NAME »] mais Django manque de superglobal facile. Par exemple, dans l'exemple de blog hostname est/etc/hostname pas le vhost.

Toutes les idées ont été appréciées.

Edit:

J'ai une solution de contournement de toutes sortes (mais idéalement, je préfèrerais un plus portable) en ajoutant un/chemin/vers/django_in_debug/la sys.path du mydomaincom.myprodserver. com vhost entrée. Puis dans le fichier settings.py

try: 
    from django_in_debug.settings import * 
except: 
    DEBUG = False 

Answer 1

Ce que vous demandez de faire est un peu plus complexe qu'il n'y paraît. Vous voulez afficher les informations de débogage pour certains INTERNAL_IPS qui se passe au niveau de la requête. Cependant, vous parlez de settings.py qui est au au niveau du site.

Pour y parvenir, vous devriez avoir ré-évalué settings.py pour chaque requête, ce qui, comme vous pouvez le constater, est probablement une très mauvaise direction. La documentation propre à Django, modifier les paramètres du site après le chargement est un non-non (pour être honnête, les gens s'en tirent, mais ça ne vaut rien pour la position officielle de Django).

est ici une idée pour vous:

Vous avez 2 fichiers WSGI. Le premier fichier WSGI pointe vers votre fichier settings.py principal, et apache redirige le trafic de www.yourdomain.com vers celui-ci. Le deuxième fichier WSGI pointe vers debug_settings.py, et apache redirige le trafic de debug.yourdomain.com vers celui-ci. debug_settinsg.py ressemble à ceci:

from settings import * 

DEBUG = True 
TEMPLATE_DEBUG = DEBUG 

De là, vous écrivez un composant simple middleware pour intercepter les requêtes entrantes. La demande IP est comparée aux paramètres.INTERNAL_IPS et si une correspondance est trouvée, la demande est redirigée vers debug.yourdomain.com. Cela vous permet de conserver une copie du site, mais de modifier un paramètre au niveau du site en fonction d'une valeur au niveau de la demande.