Quando estiver rondando um site público você deve sempre desligar a definição DEBUG . Isso fará que seu servidor rode bem mais rápido, e também irá evitar que usuários maliciosos vejam detalhes da sua aplicação que podem ser revelados por erros em suas páginas.
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.
Quando DEBUG é False, Django irá enviar um email aos usuários listados no ADMINS mesmo que seu código levante uma exceção e resulte em um erro interno ( falando estritamente, para qualquer response com um código de status de 500 ou maior). Isso dá ao administrador uma notificação imediata de quaisquer erros. Os ADMINS irão rceber uma descrição do erro, um Traceback completo do Python, e detalhes da requisição HTTP causada pelo erro.
Por padrão, o Django envia email do root@localhost. Contudo, alguns provedores de email rejeitam todos os email deste endereço. Para usar um endereço de remetente diferente, modifique a configuração SERVER_EMAIL
Para ativar este comportamento, coloque o endereço de email dos destinatários na definição do ADMINS
O Django pode ser configurado para enviar emails com erros sobre links quebrados (erros 404 “página não encontrada”). O Django envia emails com erros 404 quando:
\nDEBUG é False;
Sua definição de MIDDLEWARE inclue django.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.
Você pode dizer ao Django para parar de reportar 404s ajustando a definição do IGNORABLE_404_URLS. Isso deve ser uma lista de objetos compilados de expressões regulares. Por exeplo:
import re\n\nIGNORABLE_404_URLS = [\n re.compile(r"\\.(php|cgi)$"),\n re.compile(r"^/phpmyadmin/"),\n]\nNeste exemplo, um 404 para qualquer URL com .php``ou ``.cgi não será reportado. Nem nenhuma URL começando com /phpadmin/.
O exemplo seguinte mostra como excluir algumas URLs convencionais que “borwsers” e “crawlers” requisitam com frequência.
\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(repare que essas são expressões regulares, então coloca-se uma barra invertida na frente dos pontos para que não sejam substituidos.)
\nSe quer personalizar o comportamentdo do django.middleware.common.BrokenLinkEmailsMiddleware mais adiante (por exemplo para ignorar requisições vindas de rastreadores web), você deve criar uma subclasse e sobrescreva seus métodos.
Relatórios de erros são de grande ajuda para detectar falhas, sempre é util registrar o máximo de informação sobre falhas quanto possível. Por exemplo, por padrão o Django registra
\nAlgumas vezes certos tipos de informação talvez sejam muito sensíveis e talvez não seja apropriado manter rastros, por exemplo uma senha de usuário ou número do cartão de crédito. Então para filtrar definições que aparentam ser sensíveis como descrito na documentação do DEBUG, o Django oferece um conjunto de decoradores de função para auxiliar no controle de qual informação deve ser filtrada para fora dos relatórios de erro em um ambiente de produção (isto é, onde DEBUG é definido como False): sensitive_variables() e sensitive_post_parameters().
Se uma função (uma view ou callback) no seu código usa variavéis locais que venham guardar informação sigilosa, voce deve reguasdar o valor dessas variavéis de serem expostas nos relatórios de erros usando o decorator ‘’sensitive_variables’’
\nfrom 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.
Para esconder sistematicamente todas as variáveis locais de uma fução dos logs de erros, não forneça argumento ao decorador sensitive_variables:
@sensitive_variables()\ndef my_function(): ...\nSe uma de suas “views” recebe um objeto HttpRequest com parâmetros do POST suscetível a conter informação sensível, é possível evitar que os valores destes parâmetros sejam incluídos no relatório de erros usando o “decorator” sensitive_post_parameters
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.
Para esconder sistematicamente todos os parâmetros do POST de uma requisição em um relatório de erro relatório, não forneça nenhum arguento para o “decorator” sensitive_post_parameters:
@sensitive_post_parameters()\ndef my_view(request): ...\nTodos os parâmentros do POST são sistematicamente filtrados do relatório para certas “views” django.contrib.auth.views (login, password_reset_confirm, password_change, e add_view e user_change_password no auth admin) para prevenir o vazamento de informação sensível tal como as senhas de usuários.
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"\nVocê pode controlar de uma maneira mais granular qual filtro usar dentro de qualquer “view” configurando o atributo exception_reporter_filter do HttpRequest:
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|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