When you’re running a public site you should always turn off the\nDEBUG setting. That will make your server run much faster, and will\nalso prevent malicious users from seeing details of your application that can be\nrevealed by the error pages.
However, running with DEBUG set to False means you’ll never see\nerrors generated by your site – everyone will just see your public error pages.\nYou need to keep track of errors that occur in deployed sites, so Django can be\nconfigured to create reports with details about those errors.
When DEBUG is False, Django will email the users listed in the\nADMINS setting whenever your code raises an unhandled exception and\nresults in an internal server error (HTTP status code 500). This gives the\nadministrators immediate notification of any errors. The ADMINS will\nget a description of the error, a complete Python traceback, and details about\nthe HTTP request that caused the error.
By default, Django will send email from root@localhost. However, some mail\nproviders reject all email from this address. To use a different sender\naddress, modify the SERVER_EMAIL setting.
To activate this behavior, put the email addresses of the recipients in the\nADMINS setting.
Django can also be configured to email errors about broken links (404 “page\nnot found” errors). Django sends emails about 404 errors when:
\nDEBUG is False;
Your MIDDLEWARE setting includes\ndjango.middleware.common.BrokenLinkEmailsMiddleware.
If those conditions are met, Django will email the users listed in the\nMANAGERS setting whenever your code raises a 404 and the request has\na referer. It doesn’t bother to email for 404s that don’t have a referer –\nthose are usually just people typing in broken URLs or broken Web bots. It also\nignores 404s when the referer is equal to the requested URL, since this\nbehavior is from broken Web bots too.
You can tell Django to stop reporting particular 404s by tweaking the\nIGNORABLE_404_URLS setting. It should be a list of compiled\nregular expression objects. For example:
import re\nIGNORABLE_404_URLS = [\n re.compile(r'\\.(php|cgi)$'),\n re.compile(r'^/phpmyadmin/'),\n]\nIn this example, a 404 to any URL ending with .php or .cgi will not be\nreported. Neither will any URL starting with /phpmyadmin/.
The following example shows how to exclude some conventional URLs that browsers and\ncrawlers often request:
\nimport re\nIGNORABLE_404_URLS = [\n re.compile(r'^/apple-touch-icon.*\\.png$'),\n re.compile(r'^/favicon\\.ico$'),\n re.compile(r'^/robots\\.txt$'),\n]\n(Note that these are regular expressions, so we put a backslash in front of\nperiods to escape them.)
\nIf you’d like to customize the behavior of\ndjango.middleware.common.BrokenLinkEmailsMiddleware further (for\nexample to ignore requests coming from web crawlers), you should subclass it\nand override its methods.
Error reports are really helpful for debugging errors, so it is generally\nuseful to record as much relevant information about those errors as possible.\nFor example, by default Django records the full traceback for the\nexception raised, each traceback frame’s local variables, and the\nHttpRequest’s attributes.
However, sometimes certain types of information may be too sensitive and thus\nmay not be appropriate to be kept track of, for example a user’s password or\ncredit card number. So in addition to filtering out settings that appear to be\nsensitive as described in the DEBUG documentation, Django offers a\nset of function decorators to help you control which information should be\nfiltered out of error reports in a production environment (that is, where\nDEBUG is set to False): sensitive_variables() and\nsensitive_post_parameters().
If a function (either a view or any regular callback) in your code uses\nlocal variables susceptible to contain sensitive information, you may\nprevent the values of those variables from being included in error reports\nusing the sensitive_variables decorator:
from django.views.decorators.debug import sensitive_variables\n\n@sensitive_variables('user', 'pw', 'cc')\ndef process_info(user):\n pw = user.pass_word\n cc = user.credit_card_number\n name = user.name\n ...\nIn the above example, the values for the user, pw and cc\nvariables will be hidden and replaced with stars (**********) in the\nerror reports, whereas the value of the name variable will be\ndisclosed.
To systematically hide all local variables of a function from error logs,\ndo not provide any argument to the sensitive_variables decorator:
@sensitive_variables()\ndef my_function():\n ...\nIf one of your views receives an HttpRequest object\nwith POST parameters susceptible to\ncontain sensitive information, you may prevent the values of those\nparameters from being included in the error reports using the\nsensitive_post_parameters decorator:
from django.views.decorators.debug import sensitive_post_parameters\n\n@sensitive_post_parameters('pass_word', 'credit_card_number')\ndef record_user_profile(request):\n UserProfile.create(\n user=request.user,\n password=request.POST['pass_word'],\n credit_card=request.POST['credit_card_number'],\n name=request.POST['name'],\n )\n ...\nIn the above example, the values for the pass_word and\ncredit_card_number POST parameters will be hidden and replaced with\nstars (**********) in the request’s representation inside the error\nreports, whereas the value of the name parameter will be disclosed.
To systematically hide all POST parameters of a request in error reports,\ndo not provide any argument to the sensitive_post_parameters decorator:
@sensitive_post_parameters()\ndef my_view(request):\n ...\nAll POST parameters are systematically filtered out of error reports for\ncertain django.contrib.auth.views views (login,\npassword_reset_confirm, password_change, and add_view and\nuser_change_password in the auth admin) to prevent the leaking of\nsensitive information such as user passwords.
All sensitive_variables() and sensitive_post_parameters() do is,\nrespectively, annotate the decorated function with the names of sensitive\nvariables and annotate the HttpRequest object with the names of sensitive\nPOST parameters, so that this sensitive information can later be filtered out\nof reports when an error occurs. The actual filtering is done by Django’s\ndefault error reporter filter:\ndjango.views.debug.SafeExceptionReporterFilter. This filter uses the\ndecorators’ annotations to replace the corresponding values with stars\n(**********) when the error reports are produced. If you wish to override or\ncustomize this default behavior for your entire site, you need to define your\nown filter class and tell Django to use it via the\nDEFAULT_EXCEPTION_REPORTER_FILTER setting:
DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter'\nYou may also control in a more granular way which filter to use within any\ngiven view by setting the HttpRequest’s exception_reporter_filter\nattribute:
def my_view(request):\n if request.user.is_authenticated:\n request.exception_reporter_filter = CustomExceptionReporterFilter()\n ...\nYour custom filter class needs to inherit from\ndjango.views.debug.SafeExceptionReporterFilter and may override the\nfollowing methods:
Returns True to activate the filtering operated in the other methods.\nBy default the filter is active if DEBUG is False.
Returns the filtered dictionary of POST parameters. By default it replaces\nthe values of sensitive parameters with stars (**********).
\nReturns the filtered dictionary of local variables for the given traceback\nframe. By default it replaces the values of sensitive variables with stars\n(**********).
\n