Relatório de erroLink para este cabeçalho#

Erros do servidorsLink para este cabeçalho#

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

Erros 404Link para este cabeçalho#

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:

• DEBUG é 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
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.

Filtrando Informações sensíveisLink para este cabeçalho#

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)Link para esta definição#

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

Code

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:

Code

@sensitive_variables()
def my_function():
    ...

sensitive_post_parameters(*parameters)Link para esta definição#

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

Code

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:

Code

@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 personalizadosLink para este cabeçalho#

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 SafeExceptionReporterFilterLink para esta definição#

SafeExceptionReporterFilter.is_active(request)Link para esta definição#

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)Link para esta definição#

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)Link para esta definição#

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