Relatório de erro

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.

Relatórios por email.

Erros do servidors

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.

Nota

Para enviar o email, o Django requer algumas configurações dizendo a ele como se conectar ao seu servidor de email. No mínimo é necessário especificar EMAIL_HOST e possivelmente EMAIL_HOST_USER e EMAIL_HOST_PASSWORD, embora outras configurações tambem sejam requeridas dependendo da configuração do seu servidor de email. Consulte o Documentação de configurações do Django para uma lista completa de configurações relacionadas a email.

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

Ver também

Emails de erros de servidores são enviados usando o framework de log, e você pode customizár seu comportamento por customizando sua configuração de log.

Erros 404

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:

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.

Changed in Django 1.9:

Em versões mais antigas, 404s não eram ignorados quando o HTTP Referer era igual a URL de request.

Nota

BrokenLinkEmailsMiddleware deve aparecer antes de outros “middlewares” que interceptam 404, tal como LocaleMiddleware ou FlatpageFallbackMiddleware. Coloque-o na parte superior do seu MIDDLEWARE_CLASSES setting.

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
IGNORABLE_404_URLS = [
    re.compile(r'\.(php|cgi)$'),
    re.compile(r'^/phpmyadmin/'),
]

Neste 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.

import re
IGNORABLE_404_URLS = [
    re.compile(r'^/apple-touch-icon.*\.png$'),
    re.compile(r'^/favicon\.ico$'),
    re.compile(r'^/robots\.txt$'),
]

(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.)

Se 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.

Ver também

Erros 404 são logados usando o framework logging. Por padrão, estes registros de log são ignorados, mas você pode usá-los para relatório de erros sobrescrevendo o “handlers” e o configuring logging apropriadamente.

Filtrando relatórios de erros

Aviso

Filtrar dados sensíveis é um problema difícil, e é quase impossível garantir que dados sensíveis não vão vazar dentro de um relatório de erro. Portanto, relatórios de erros soment devem ser disponibilizados para membros confiáveis do time e você deveria evitar transmitir relatórios de erros sem incriptação através da internet (tal como através de um e-mail).

Filtrando Informações sensíveis

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

However, sometimes certain types of information may be too sensitive and thus may not be appropriate to be kept track of, for example a user’s password or credit card number. So in addition to filtering out settings that appear to be sensitive as described in the DEBUG documentation, Django offers a set of function decorators to help you control which information should be filtered out of error reports in a production environment (that is, where DEBUG is set to False): sensitive_variables() and sensitive_post_parameters().

sensitive_variables(*variables)[código fonte]

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’‘

from django.views.decorators.debug import sensitive_variables

@sensitive_variables('user', 'pw', 'cc')
def process_info(user):
    pw = user.pass_word
    cc = user.credit_card_number
    name = user.name
    ...

No 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.

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()
def my_function():
    ...

Quando usar multiplos decorators

Se a variável que você quer esconder é também um argumento da função (ex.: user no exemplo a seguir), e si a função “decorada” tem múltimplos “decorators”, então tenha certeza de posiionar o @sensitive_variables no topo da lista de “decorators”. Desta maneira, serão escondidos também o argumento da função enquanto passa pelos outros “decorators”:

@sensitive_variables('user', 'pw', 'cc')
@some_decorator
@another_decorator
def process_info(user):
    ...
sensitive_post_parameters(*parameters)[código fonte]

Se 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

@sensitive_post_parameters('pass_word', 'credit_card_number')
def record_user_profile(request):
    UserProfile.create(
        user=request.user,
        password=request.POST['pass_word'],
        credit_card=request.POST['credit_card_number'],
        name=request.POST['name'],
    )
    ...

No 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()
def my_view(request):
    ...

Todos 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.

Relatórios de erros personalizados

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'

Você 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):
    if request.user.is_authenticated():
        request.exception_reporter_filter = CustomExceptionReporterFilter()
    ...

A classe personalizada precisa herdar de django.views.debug.SafeExceptionReporterFilter e talvez sobrescrever os seguintes métodos:

class SafeExceptionReporterFilter[código fonte]
SafeExceptionReporterFilter.is_active(request)[código fonte]

Retorna True para ativar a filtragem operada nos outros métodos. Por padrão o filtro é ativo se DEBUG é False.

SafeExceptionReporterFilter.get_post_parameters(request)[código fonte]

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 (**********).

SafeExceptionReporterFilter.get_traceback_frame_variables(request, tb_frame)[código fonte]

Retorna 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 (**********).

Ver também

Você pode também configurar um relatório de erro personalizado escrevendo um pedaço personalizado middleware de exceção. Se escrever um tratamento de erros personalizado, é uma boa idéia emular o tratamento de erro do Django e somente reportar/logar erros se DEBUG é False.

Back to Top