--- title: "Relatório de erro" version: 1.9 locale: pt-br source: https://docs.djangoproject.com/pt-br/1.9/howto/error-reporting/ canonical: https://djangodocs.dev/pt-br/1.9/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.9/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.9/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 servidors Quando [`DEBUG`](/pt-br/1.9/ref/settings/#std-setting-DEBUG) é definido `False`, Django irá enviar emails para os usuários listados na configuração [`ADMINS`](/pt-br/1.9/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.9/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.9/ref/settings/#std-setting-EMAIL_HOST) e possivelmente [`EMAIL_HOST_USER`](/pt-br/1.9/ref/settings/#std-setting-EMAIL_HOST_USER) e [`EMAIL_HOST_PASSWORD`](/pt-br/1.9/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.9/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.9/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.9/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.9/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.9/ref/settings/#std-setting-DEBUG) é `False`; - Sua definição de [`MIDDLEWARE_CLASSES`](/pt-br/1.9/ref/settings/#std-setting-MIDDLEWARE_CLASSES) incluem [`django.middleware.common.BrokenLinkEmailsMiddleware`](/pt-br/1.9/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.9/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. > **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. > **Note** > > [`BrokenLinkEmailsMiddleware`](/pt-br/1.9/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) deve aparecer antes de outros “middlewares” que interceptam 404, tal como [`LocaleMiddleware`](/pt-br/1.9/ref/middleware/#django.middleware.locale.LocaleMiddleware) ou [`FlatpageFallbackMiddleware`](/pt-br/1.9/ref/contrib/flatpages/#django.contrib.flatpages.middleware.FlatpageFallbackMiddleware). Coloque-o na parte superior do seu [`MIDDLEWARE_CLASSES`](/pt-br/1.9/ref/settings/#std-setting-MIDDLEWARE_CLASSES) setting. Você pode dizer ao Django para parar de reportar 404s ajustando a definição do [`IGNORABLE_404_URLS`](/pt-br/1.9/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.9/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.9/topics/logging/) apropriadamente. ## Filtrando relatórios de erros > **Warning** > > 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`](/pt-br/1.9/ref/settings/#std-setting-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`](/pt-br/1.9/ref/settings/#std-setting-DEBUG) is set to `False`): [`sensitive_variables()`](#django.views.decorators.debug.sensitive_variables) and [`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.9/ref/request-response/#django.http.HttpRequest) com [`parâmetros do POST`](/pt-br/1.9/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.9/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.9/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.9/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.9/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.9/ref/settings/#std-setting-DEBUG) é `False`.