2

I am trying to make sure that my site is properly protected from showing the details of the error in production.

I've been struggling with this for a while, as at beginning I understood that in order to avoid Django from showing the error (module, line of code, etc.) all that was needed was changing DEBUG from True to False in settings.py.

However, I realized that Django was still showing error details, so investigating a bit more and I came to know that the following was also needed:

  • TEMPLATE_DEBUG = DEBUG in settings.py
  • 404.html and 500.htmlinside the templates folder

Is there anything else needed to make sure that the user does not get those messages?

And how does Django deal with the other kind of errors, like 400? I saw here that there are handlers for 400 and 403, but I do not understand it and I don't know if they are needed at all for a basic using case.

Antonis Christofides
  • 6,990
  • 2
  • 39
  • 57
J0ANMM
  • 7,849
  • 10
  • 56
  • 90
  • Can you give an example of what output Django is producing that you're trying to avoid? With `DEBUG` set to `False` and no custom handlers, it simply "serves the text `403 Forbidden`" (for example), according to the documentation. As far as I can tell it doesn't give any information that isn't already inherent in the HTTP status code. – Kevin Christopher Henry Feb 11 '17 at 20:14

1 Answers1

1

If DEBUG is False, Django doesn't show error details to the user. If it did in your case, the most likely explanations are either that it's not using the settings.py file you think it's using (in which case you should check the Python path, the directory from which you run manage.py, and the value of DJANGO_SETTINGS_MODULE), or that you did not restart Gunicorn/uWSGI/Apache after you made the change to settings.py (Django does not restart itself automatically in production like it does in development).

As for 400 and 403, just leave the Django defaults. If Django receives a bad request (unlikely in production, because this will usually be caught by Apache or nginx), it will call bad_request() which will just show a "400 bad request" to the user. Likewise for other errors.

Antonis Christofides
  • 6,990
  • 2
  • 39
  • 57
  • Indeed, the issue was that I had two setting files in a settings folder: `local.py` and `production.py` as explained [here](http://stackoverflow.com/a/15325966/5802289). `local.py` was in my `.gitignore` but somehow it was once included in the repository, so once included it does not matter if it is contained in the `.gitignore`, it will not be removed automatically. To achieve that it was actually excluded from the repository so only `production.py` was included, I had to run `git rm --cached django_project/settings/local.py` – J0ANMM Feb 12 '17 at 09:19