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 instead see your public error\npages. You need to keep track of errors that occur in deployed sites, so Django\ncan be configured 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 (strictly speaking, for any response with\nan HTTP status code of 500 or greater). This gives the administrators immediate\nnotification of any errors. The ADMINS will get a description of the\nerror, a complete Python traceback, and details about the HTTP request that\ncaused 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 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\n\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\n\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\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 (**********)\nin the error 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(): ...\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\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\nerror reports, whereas the value of the name parameter will be\ndisclosed.
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): ...\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\noverride or customize this default behavior for your entire site, you need to\ndefine your own 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 attributes and methods:
The string value to replace sensitive value with. By default it\nreplaces the values of sensitive variables with stars\n(**********).
A compiled regular expression object used to match settings and\nrequest.META values considered as sensitive. By default equivalent\nto:
import re\n\nre.compile(r"API|AUTH|TOKEN|KEY|SECRET|PASS|SIGNATURE|HTTP_COOKIE", flags=re.IGNORECASE)\nReturns True to activate the filtering in\nget_post_parameters() and get_traceback_frame_variables().\nBy default the filter is active if DEBUG is False. Note\nthat sensitive request.META values are always filtered along with\nsensitive setting values, as described in the DEBUG\ndocumentation.
Returns the filtered dictionary of POST parameters. Sensitive values\nare replaced with cleansed_substitute.
Returns the filtered dictionary of local variables for the given\ntraceback frame. Sensitive values are replaced with\ncleansed_substitute.
If you need to customize error reports beyond filtering you may specify a\ncustom error reporter class by defining the\nDEFAULT_EXCEPTION_REPORTER setting:
DEFAULT_EXCEPTION_REPORTER = "path.to.your.CustomExceptionReporter"\nThe exception reporter is responsible for compiling the exception report data,\nand formatting it as text or HTML appropriately. (The exception reporter uses\nDEFAULT_EXCEPTION_REPORTER_FILTER when preparing the exception\nreport data.)
Your custom reporter class needs to inherit from\ndjango.views.debug.ExceptionReporter.
Property that returns a pathlib.Path representing the absolute\nfilesystem path to a template for rendering the HTML representation of\nthe exception. Defaults to the Django provided template.
Property that returns a pathlib.Path representing the absolute\nfilesystem path to a template for rendering the plain-text\nrepresentation of the exception. Defaults to the Django provided\ntemplate.
Return a dictionary containing traceback information.
\nThis is the main extension point for customizing exception reports, for\nexample:
\nfrom django.views.debug import ExceptionReporter\n\n\nclass CustomExceptionReporter(ExceptionReporter):\n def get_traceback_data(self):\n data = super().get_traceback_data()\n # ... remove/add something here ...\n return data\nReturn HTML version of exception report.
\nUsed for HTML version of debug 500 HTTP error page.
\nReturn plain text version of exception report.
\nUsed for plain text version of debug 500 HTTP error page and email\nreports.
\nAs with the filter class, you may control which exception reporter class to use\nwithin any given view by setting the HttpRequest’s\nexception_reporter_class attribute:
def my_view(request):\n if request.user.is_authenticated:\n request.exception_reporter_class = CustomExceptionReporter()\n ...\n