views:

152

answers:

1

I'm looking for a safe method of triggering DEBUG for INTERNAL_IPS requests on a django production server without requiring the alteration of a settings.py file. Mainly to get the toolbar going for some designers to check issues on live data/media, but without relying on them to reset the settings once they have finished.

Similar to this method. hovever this only suits deployment.

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

in the past on php based systems I've had mydomain.com and a demo mydomaincom.myprodserver.com where the prodserver domain can automatically run debug code based on $_SERVER['HOST_NAME'] but django is lacking the easy superglobal. eg in the blog example hostname is the /etc/hostname not the vhost.

Any ideas appreciated.

Edit:

I have a workaround solution of sorts (but ideally I'd prefer a more portable one) by adding a /path/to/django_in_debug/ to the sys.path of the mydomaincom.myprodserver.com vhost entry. Then in the settings.py file

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

What you're asking to do is a bit more complex than it seems. You want to show debug information for certain INTERNAL_IPS which is happening at the request-level. However, you're talking about settings.py which is at the site-level.

To achieve this then, you would have to have the settings.py being re-evaluated per each request, which as you can tell is probably a very bad direction. Per Django's own documentation, modifying the settings of the site after it has loaded is a no-no (to be fair people get away with this, but it's worth nothing Django's official stance).

Here's an idea for you:

You have 2 WSGI files. The first WSGI file points to your main settings.py, and apache directs traffic from www.yourdomain.com to it.. The second WSGI file points to debug_settings.py, and apache redirects traffic from debug.yourdomain.com to it. debug_settinsg.py looks like this:

from settings import *

DEBUG = True
TEMPLATE_DEBUG = DEBUG

From here you write a simple middleware component to trap incoming requests. The request IP is compared to the settings.INTERNAL_IPS and if a match is found the request is redirected to debug.yourdomain.com.

This allows you to keep 1 copy of the site, but change a site-level setting based on a request-level value.

T. Stone
+1 It's especially important to keep DEBUG out of the primary domain due to Django saving all database queries when DEBUG=True... eats up memory fast.
Van Gale
cheers, this is a better solution
michael
It might also be worth investigating having apache do the redirect for you instead of middleware
T. Stone