--- title: "Relatório de erro" version: 1.11 locale: pt-br source: https://docs.djangoproject.com/pt-br/1.11/howto/error-reporting/ canonical: https://djangodocs.dev/pt-br/1.11/howto/error-reporting/ --- # Relatório de erro Quando estiver rondando um site público você deve sempre desligar a definição [`DEBUG`](/pt-br/1.11/ref/settings/#std-setting-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`](/pt-br/1.11/ref/settings/#std-setting-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 servidor Quando [`DEBUG`](/pt-br/1.11/ref/settings/#std-setting-DEBUG) é definido `False`, Django irá enviar emails para os usuários listados na configuração [`ADMINS`](/pt-br/1.11/ref/settings/#std-setting-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`](/pt-br/1.11/ref/settings/#std-setting-ADMINS) receberá uma descrição do erro, uma histórico Python completo, e detalhes sobre a requisição HTTP que causou o erro. > **Note** > > 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`](/pt-br/1.11/ref/settings/#std-setting-EMAIL_HOST) e possivelmente [`EMAIL_HOST_USER`](/pt-br/1.11/ref/settings/#std-setting-EMAIL_HOST_USER) e [`EMAIL_HOST_PASSWORD`](/pt-br/1.11/ref/settings/#std-setting-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](/pt-br/1.11/ref/settings/) para uma lista completa de configurações relacionadas a email. Por padrão, o Django envia email do [root@localhost](mailto: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`](/pt-br/1.11/ref/settings/#std-setting-SERVER_EMAIL) Para ativar este comportamento, coloque o endereço de email dos destinatários na definição do [`ADMINS`](/pt-br/1.11/ref/settings/#std-setting-ADMINS) > **See also** > > 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](/pt-br/1.11/topics/logging/). ### 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: - [`DEBUG`](/pt-br/1.11/ref/settings/#std-setting-DEBUG) é `False`; - Sua definição de [`MIDDLEWARE`](/pt-br/1.11/ref/settings/#std-setting-MIDDLEWARE) inclue [`django.middleware.common.BrokenLinkEmailsMiddleware`](/pt-br/1.11/ref/middleware/#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`](/pt-br/1.11/ref/settings/#std-setting-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. > **Note** > > A [`BrokenLinkEmailsMiddleware`](/pt-br/1.11/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) deve aparecer antes de outros middlewares que interceptam erros 404, tal como [`LocaleMiddleware`](/pt-br/1.11/ref/middleware/#django.middleware.locale.LocaleMiddleware) ou [`FlatpageFallbackMiddleware`](/pt-br/1.11/ref/contrib/flatpages/#django.contrib.flatpages.middleware.FlatpageFallbackMiddleware). Coloque-os mais próximo do topo da sua definição do [`MIDDLEWARE`](/pt-br/1.11/ref/settings/#std-setting-MIDDLEWARE). Você pode dizer ao Django para parar de reportar 404s ajustando a definição do [`IGNORABLE_404_URLS`](/pt-br/1.11/ref/settings/#std-setting-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`](/pt-br/1.11/ref/middleware/#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. > **See also** > > 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](/pt-br/1.11/topics/logging/) apropriadamente. ## Filtrando relatórios de erros > **Warning** > > A filtragem de dados confidenciais é um problema difícil, e é quase impossível garantir que os dados confidenciais não vazarão em um relatório de erros. Portanto, os relatórios de erros só devem estar disponíveis para membros confiáveis da equipe e você deve evitar a transmissão de relatórios de erros não encriptados pela Internet (como por 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 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`](/pt-br/1.11/ref/settings/#std-setting-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`](/pt-br/1.11/ref/settings/#std-setting-DEBUG) é definido como `False`): [`sensitive_variables()`](#django.views.decorators.debug.sensitive_variables) e [`sensitive_post_parameters()`](#django.views.decorators.debug.sensitive_post_parameters). #### `sensitive_variables(*variables)` 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)` Se uma de suas “views” recebe um objeto [`HttpRequest`](/pt-br/1.11/ref/request-response/#django.http.HttpRequest) com [`parâmetros do POST`](/pt-br/1.11/ref/request-response/#django.http.HttpRequest.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`](/pt-br/1.11/topics/auth/default/#module-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()`](#django.views.decorators.debug.sensitive_variables) e [`sensitive_post_parameters()`](#django.views.decorators.debug.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`](#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`](/pt-br/1.11/ref/settings/#std-setting-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`](#django.views.debug.SafeExceptionReporterFilter) e talvez sobrescrever os seguintes métodos: #### `class SafeExceptionReporterFilter` #### `SafeExceptionReporterFilter.is_active(request)` Retorna `True` para ativar a filtragem operada nos outros métodos. Por padrão o filtro é ativo se [`DEBUG`](/pt-br/1.11/ref/settings/#std-setting-DEBUG) é `False`. #### `SafeExceptionReporterFilter.get_post_parameters(request)` 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)` 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 (\*\*\*\*\*\*\*\*\*\*). > **See also** > > Você pode também configurar um relatório de erro personalizado escrevendo um pedaço personalizado [middleware de exceção](/pt-br/1.11/topics/http/middleware/#exception-middleware). 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`](/pt-br/1.11/ref/settings/#std-setting-DEBUG) é `False`.