28👍
https://docs.djangoproject.com/en/dev/ref/settings/#debug
“Never deploy a site into production with DEBUG turned on.
Did you catch that? NEVER deploy a site into production with DEBUG turned on.
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).”
Basically, it’s a gaping security hole.
It also wastes a lot of memory:
“It is also important to remember that when running with DEBUG turned on, Django will remember every SQL query it executes. This is useful when you’re debugging, but it’ll rapidly consume memory on a production server.”
21👍
Django tries its best to obfuscate secure information in your debug page, but it’s not perfect.
By default any settings which include KEY (starting Django 1.4), SECRET etc. are automatically replaced with *. However if someone decides to get creative and call SECRET as SECURE_STR or whatever, that will be displayed as plain text! Would you want that? Also it’s just more fodder for someone to hack into your server easily.
- [Django]-Django: Filter a Queryset made of unions not working
- [Django]-Django @login_required decorator for a superuser
- [Django]-How can I tell the Django ORM to reverse the order of query results?
0👍
If the DEBUG = True
Django raised detailed error page, it contains every url details as well as our important credentials also, it is helpful for developers to understanding and solve bugs. In the production time must keep DEBUG = False to avoid the detailed error page.
- [Django]-Class Based Views VS Function Based Views
- [Django]-Display only some of the page numbers by django pagination
- [Django]-IOError: request data read error