Cómo activar django DEBUG en un servidor de producción de forma no intrusiva

Question

Estoy buscando un método seguro para desencadenar DEBUG para solicitudes INTERNAL_IPS en un servidor de producción django sin requerir la alteración de un archivo settings.py. Principalmente para que la barra de herramientas funcione para que algunos diseñadores verifiquen los problemas en los datos/medios en vivo, pero sin depender de ellos para restablecer la configuración una vez que hayan finalizado.

Similar a este método. aunque esto solo se adapta a la implementación.

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

en el pasado en los sistemas basados ​​en php que he tenido mydomain.com y una demostración mydomaincom.myprodserver.com donde el dominio prodserver puede ejecutar automáticamente el código de depuración basado en $ _SERVER [ 'HOST_NAME'], pero django le falta el superglobal fácil. por ejemplo, en el nombre de host de ejemplo de blog es/etc/hostname no el vhost.

Cualquier idea apreciada.

Editar:

tengo una solución solución del tipo (pero lo ideal es que preferiría una más portátiles) mediante la adición de un/ruta/a/django_in_debug/a sys.path del mydomaincom.myprodserver. com entrada de host. Luego en el archivo settings.py

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

Answer 1

Lo que estás pidiendo hacer es un poco más complejo de lo que parece. Desea mostrar la información de depuración para ciertos INTERNAL_IPS que está ocurriendo en el nivel de solicitud. Sin embargo, está hablando de settings.py que está en el nivel de sitio.

Para lograr esto, tendría que volver a evaluar settings.py por cada solicitud, que como puede ver es probablemente una muy mala dirección. Según la propia documentación de Django, modificar la configuración del sitio después de que se haya cargado es un no-no (para ser justos, la gente se sale con la suya, pero no vale la pena la postura oficial de Django).

He aquí una idea para usted:

Tienes 2 archivos WSGI. El primer archivo WSGI apunta a su settings.py principal, y apache dirige el tráfico de www.yourdomain.com a él. El segundo archivo WSGI apunta a debug_settings.py, y apache redirecciona el tráfico de debug.yourdomain.com a él. debug_settinsg.py se ve así:

from settings import * 

DEBUG = True 
TEMPLATE_DEBUG = DEBUG 

Desde aquí se escribe un componente middleware sencilla para atrapar las peticiones entrantes. La IP de la solicitud se compara con la configuración.INTERNAL_IPS y si se encuentra una coincidencia, la solicitud se redirige a debug.yourdomain.com.

Esto le permite mantener 1 copia del sitio, pero cambiar una configuración de nivel de sitio basado en un valor de nivel de solicitud.