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.
Contudo, rodar com DEBUG definido como ``False``quer dizer que você nunca verá os erros gerados pelo seu site – todos verão somente sua página pública de erro. É necessário rastrear os erros que ocorrem em sites publicados, então o Django pode ser configurado para criar relatorios com detahes sobre este erros.
Quando DEBUG é definido False, Django irá enviar emails para os usuários listados na configuração ADMINS sempre que seu código gerar uma exceção não tratada e resulta em um erro interno do servidor (código de status HTTP 500). Isso dá aos administradores uma notificação imediata de qualquer erro. O ADMINS receberá uma descrição do erro, uma histórico Python completo, e detalhes sobre a requisição HTTP que causou o 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_CLASSES incluem django.middleware.common.BrokenLinkEmailsMiddleware.
Se estas condições são encontradas, o Django irá enviar emails aos usuários listados na definição de MANAGERS sempre que seu código gerar um 404 e o request possui um HTTP Referer. Ele não se preocupa em enviar email para 404 que não tenham um HTTP Referer – estes são geralmente pessoas digitando URLs quebradas ou robôs Web quebrados. Ele também ignora 404s quando o referente é igual a URL requisitada, já que este comportamento provém também de robôs Web quebrados.
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\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\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
\nHowever, 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().
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@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 ...\nNo exemplo anterior, os valores de “user”, “pw” e “cc” serão ocultados e trocados por asteríscos (**********) nos relatórios de erros, onde quer que o valor da variavel “name” seja exibido.
\nPara 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():\n ...\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@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 ...\nNo exemplo acima, os valores dos para parâmetros pass_word e credit_card_number do POST serão escondidos e substituídos por asteríscos (**********) na representação da requisição dentro do relatório de erro, independente de onde o valor do parâmetro name seja mostrado.
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):\n ...\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.
Tudo que sensitive_variables() e sensitive_post_parameters() fazem é, respectivamente, anota a função decorada com os nomes das variáveis sensíveis e anota o objeto HttpRequest com o nome dos parâmetros sensíveis do POST, tal que essa informação sensível pode mais tarde ser filtrada dos relatórios quando um erro ocorrer. O filtro é feito pelo filtro de relatório de erros padrão do Django : django.views.debug.SafeExceptionReporterFilter. Este filtro usa a anotação de decoradores para substituir os valores correspondentes por asteríscos (**********) quando o relatório é produzido. Se quiser sobrescrever ou customizar o compartamento padrão para todo o site, é preciso definir sua própria classe de filtro e indicar ao Django para usá-la através da definição DEFAULT_EXCEPTION_REPORTER_FILTER
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 ...\nA classe personalizada precisa herdar de django.views.debug.SafeExceptionReporterFilter e talvez sobrescrever os seguintes métodos:
Retorna True para ativar a filtragem operada nos outros métodos. Por padrão o filtro é ativo se DEBUG é False.
Retorna o dicionário filtrado dos parâmetros do POST. Por padrão ele substitui os valores dos parâmetros sensíveis por asteríscos (**********).
\nRetorna o dicionário filtrado de variáveis globais para um dado quadro do “traceback”. Por padrão ele substitui os valores de variáveis sensíveis por asteríscos (**********).
\n