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.
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.
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.
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.
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).
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.
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:
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
.
ago 01, 2016