How to manage error reportingLink para este cabeçalho#

Erros do servidorLink para este cabeçalho#

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.

By default, Django will send email from root@localhost. However, some mail providers reject all email from this address. To use a different sender address, modify the SERVER_EMAIL setting.

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 inclue django.middleware.common.BrokenLinkEmailsMiddleware.

If those conditions are met, Django will email the users listed in the MANAGERS setting whenever your code raises a 404 and the request has a referer. It doesn’t bother to email for 404s that don’t have a referer – those are usually people typing in broken URLs or broken web bots. It also ignores 404s when the referer is equal to the requested URL, since this behavior 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

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

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

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

In the above example, the values for the user, pw and cc variables will be hidden and replaced with stars (**********) in the error reports, whereas the value of the name variable will be disclosed.

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#

If one of your views receives an HttpRequest object with POST parameters susceptible to contain sensitive information, you may prevent the values of those parameters from being included in the error reports using the sensitive_post_parameters decorator:

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"],
    )
    ...

In the above example, the values for the pass_word and credit_card_number POST parameters will be hidden and replaced with stars (**********) in the request’s representation inside the error reports, whereas the value of the name parameter will be disclosed.

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#

All sensitive_variables() and sensitive_post_parameters() do is, respectively, annotate the decorated function with the names of sensitive variables and annotate the HttpRequest object with the names of sensitive POST parameters, so that this sensitive information can later be filtered out of reports when an error occurs. The actual filtering is done by Django’s default error reporter filter: django.views.debug.SafeExceptionReporterFilter. This filter uses the decorators’ annotations to replace the corresponding values with stars (**********) when the error reports are produced. If you wish to override or customize this default behavior for your entire site, you need to define your own filter class and tell Django to use it via the DEFAULT_EXCEPTION_REPORTER_FILTER setting:

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

Your custom filter class needs to inherit from django.views.debug.SafeExceptionReporterFilter and may override the following attributes and methods:

class SafeExceptionReporterFilterLink para esta definição#

cleansed_substituteLink para esta definição#

The string value to replace sensitive value with. By default it replaces the values of sensitive variables with stars (**********).

hidden_settingsLink para esta definição#

A compiled regular expression object used to match settings and request.META values considered as sensitive. By default equivalent to:

Code

import re

re.compile(r"API|AUTH|TOKEN|KEY|SECRET|PASS|SIGNATURE|HTTP_COOKIE", flags=re.IGNORECASE)

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

Returns True to activate the filtering in get_post_parameters() and get_traceback_frame_variables(). By default the filter is active if DEBUG is False. Note that sensitive request.META values are always filtered along with sensitive setting values, as described in the DEBUG documentation.

get_post_parameters(request)Link para esta definição#

Returns the filtered dictionary of POST parameters. Sensitive values are replaced with cleansed_substitute.

get_traceback_frame_variables(request, tb_frame)Link para esta definição#

Returns the filtered dictionary of local variables for the given traceback frame. Sensitive values are replaced with cleansed_substitute.

If you need to customize error reports beyond filtering you may specify a custom error reporter class by defining the DEFAULT_EXCEPTION_REPORTER setting:

DEFAULT_EXCEPTION_REPORTER = "path.to.your.CustomExceptionReporter"

The exception reporter is responsible for compiling the exception report data, and formatting it as text or HTML appropriately. (The exception reporter uses DEFAULT_EXCEPTION_REPORTER_FILTER when preparing the exception report data.)

Your custom reporter class needs to inherit from django.views.debug.ExceptionReporter.

class ExceptionReporterLink para esta definição#

html_template_pathLink para esta definição#

Property that returns a pathlib.Path representing the absolute filesystem path to a template for rendering the HTML representation of the exception. Defaults to the Django provided template.

text_template_pathLink para esta definição#

Property that returns a pathlib.Path representing the absolute filesystem path to a template for rendering the plain-text representation of the exception. Defaults to the Django provided template.

get_traceback_data()Link para esta definição#

Return a dictionary containing traceback information.

This is the main extension point for customizing exception reports, for example:

Code

from django.views.debug import ExceptionReporter


class CustomExceptionReporter(ExceptionReporter):
    def get_traceback_data(self):
        data = super().get_traceback_data()
        # ... remove/add something here ...
        return data

get_traceback_html()Link para esta definição#

Return HTML version of exception report.

Used for HTML version of debug 500 HTTP error page.

get_traceback_text()Link para esta definição#

Return plain text version of exception report.

Used for plain text version of debug 500 HTTP error page and email reports.

As with the filter class, you may control which exception reporter class to use within any given view by setting the HttpRequest’s exception_reporter_class attribute:

def my_view(request):
    if request.user.is_authenticated:
        request.exception_reporter_class = CustomExceptionReporter()
    ...