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
If you want to debug Django using PTVS, you need to do the following: In Project settings - General tab, set "Startup File" to "manage.py", the entry point of the Django program. In Project settings - Debug tab, set "Script Arguments" to "runserver --noreload". The key point is the "--noreload" here.
One of the main features of debug mode is the display of detailed error pages. If your app raises an exception when DEBUG is True, Django will display a detailed traceback, including a lot of metadata about your environment, such as all the currently defined Django settings (from settings.py).
Open your settings.py file (or settings_local.py ) and set DEBUG = False (just add that line if necessary). Turning off the Django debug mode will: Suppress the verbose Django error messages in favor of a standard 404 or 500 error page. You will now find Django error messages printed in your arches.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With