Отчет об ошибках ¶
При запуске общедоступного сайта вы всегда должны отключать эту настройку DEBUG
. Это ускорит работу сервера, а также предотвратит возможность просмотра злоумышленниками сведений о приложении, которые могут отображаться на страницах с ошибками.
Однако, когда сайт работает с DEBUG
установленным значением False
, вы никогда не увидите подробную информацию о каких-либо ошибках, сгенерированных сайтом; все видят одни и те же публичные страницы ошибок. Необходимо отслеживать ошибки, возникающие на рабочих сайтах, поэтому можно настроить Django для создания отчетов, содержащих подробную информацию об этих ошибках.
Отчеты по электронной почте ¶
Ошибки сервера ¶
Когда DEBUG
установлено False
, Django отправляет электронное письмо пользователям, указанным в настройке, ADMINS
всякий раз, когда код генерирует неперехваченное исключение, которое вызывает внутреннюю ошибку сервера (строго говоря, для любого ответа с кодом состояния HTTP 500 или выше). Таким образом, администраторы немедленно уведомляются о любой ошибке. Люди ADMINS
получают описание ошибки, полную трассировку Python и подробную информацию о HTTP-запросе, вызвавшем ошибку.
Заметка
Чтобы иметь возможность отправлять электронные письма, Django необходимо знать некоторые настройки, указывающие, как подключиться к почтовому серверу. Как минимум необходимо указать EMAIL_HOST
, а потенциально EMAIL_HOST_USER
и EMAIL_HOST_PASSWORD
; Однако, в зависимости от конфигурации почтового сервера, могут потребоваться другие настройки. См. Документацию по настройкам Django для получения полного списка настроек, связанных с отправкой сообщений электронной почты.
По умолчанию Django отправляет свои сообщения на исходный адрес root @ localhost . Однако некоторые поставщики услуг электронной почты отклоняют все сообщения с этого адреса. Чтобы использовать другой адрес отправителя, измените настройку SERVER_EMAIL
.
Чтобы включить это поведение, укажите в настройках адреса электронной почты получателя ADMINS
.
Смотрите также
Сообщения об ошибках сервера отправляются через инфраструктуру ведения журнала, поэтому такое поведение можно настроить , настроив конфигурацию ведения журнала .
404 ошибки ¶
Django также можно настроить для отправки электронных писем при ошибках неработающих ссылок (404 ошибки «страница не найдена»). Django отправляет электронные письма с ошибкой 404, если:
DEBUG
стоитFalse
;- Ваша настройка
MIDDLEWARE
содержитdjango.middleware.common.BrokenLinkEmailsMiddleware
.
Если эти условия соблюдены, Django отправляет электронное письмо пользователям, указанным в настройке, MANAGERS
всякий раз, когда код сообщает об ошибке 404, а запрос имеет URL-адрес реферера. Он не беспокоит отправку электронного письма с ошибкой 404 без URL-адреса реферера, так как обычно это люди, которые ввели неправильный адрес или ошибочные веб-боты. Он также игнорирует ошибки 404, когда ссылающийся URL-адрес совпадает с запрошенным, поскольку такое поведение также типично для неисправных веб-ботов.
Заметка
BrokenLinkEmailsMiddleware
должен появиться перед любым другим промежуточным программным обеспечением, перехватывающим ошибку 404, например LocaleMiddleware
или FlatpageFallbackMiddleware
. Поместите его в первые ряды настройки MIDDLEWARE
.
Можно указать Django не сообщать об определенных ошибках 404, изменив настройку IGNORABLE_404_URLS
. Это список скомпилированных регулярных выражений. Например :
import re
IGNORABLE_404_URLS = [
re.compile(r'\.(php|cgi)$'),
re.compile(r'^/phpmyadmin/'),
]
В этом примере ошибка 404 для любого URL-адреса, заканчивающегося на .php
или .cgi
, не будет сообщаться. Ни URL, начинающийся с /phpmyadmin/
.
В следующем примере показано, как исключить определенные URL-адреса, которые обычно запрашиваются браузерами и роботами:
import re
IGNORABLE_404_URLS = [
re.compile(r'^/apple-touch-icon.*\.png$'),
re.compile(r'^/favicon\.ico$'),
re.compile(r'^/robots\.txt$'),
]
(Обратите внимание, что это регулярные выражения, поэтому перед точками стоит обратная косая черта.)
Если вы хотите дополнительно настроить поведение django.middleware.common.BrokenLinkEmailsMiddleware
(например, чтобы игнорировать запросы от веб-роботов), вы должны создать подкласс и переопределить его методы.
Смотрите также
404 ошибки регистрируются с помощью инфраструктуры ведения журналов. По умолчанию эти записи журнала игнорируются, но вы можете использовать их для отчетов об ошибках, написав обработчик и соответствующим образом настроив ведение журнала .
Отчеты об ошибках фильтрации ¶
Предупреждение
Фильтрация конфиденциальных данных - сложная проблема, и практически невозможно гарантировать, что конфиденциальные данные не появятся в отчете об ошибке. Поэтому вам следует ограничить доступ к отчетам об ошибках надежным членам вашей команды и избегать передачи этих отчетов в незашифрованном виде через Интернет (например, по электронной почте).
Фильтрация конфиденциальной информации ¶
Отчеты об ошибках действительно полезны для отладки ошибок, поэтому обычно полезно получить о них как можно больше информации. По умолчанию Django собирает полную трассировку сгенерированного исключения, локальные переменные каждого контекста трассировки и атрибуты объекта HttpRequest
.
Однако может случиться так, что некоторые типы информации будут слишком конфиденциальными и их будет недостаточно, например, пароль или номер кредитной карты. Таким образом, помимо исключения настроек, которые кажутся конфиденциальными, как описано в документации DEBUG
, Django предлагает набор функций декоратора, которые помогут вам контролировать, какая информация не должна отображаться в отчетах об ошибках в файле. production (то есть когда DEBUG
установлено значение False
): sensitive_variables()
и sensitive_post_parameters()
.
-
sensitive_variables
( * переменные ) ¶ Если функция (представление или любая другая функция обратного вызова) в вашем коде использует локальные переменные, которые могут содержать конфиденциальную информацию, вы можете предотвратить появление значений этих переменных в отчетах об ошибках с помощью декоратора
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 ...
В приведенном выше примере, значение переменных
user
,pw
иcc
будет скрыто и заменено звездами (**********
) в отчетах об ошибках, в то время как значение переменногоname
будет видно.Чтобы всегда скрывать все локальные переменные функции в журналах ошибок, не передавайте никаких параметров декоратору
sensitive_variables
:@sensitive_variables() def my_function(): ...
Использование нескольких декораторов
Если переменная, которую вы хотите скрыть, также является параметром функции (например,
user
в следующем примере) и если декорированная функция имеет несколько декораторов, обязательно поместите декораторы@sensitive_variables
в верхнюю часть цепочки. Таким образом, параметр функции также будет скрыт при прохождении через другие декораторы:@sensitive_variables('user', 'pw', 'cc') @some_decorator @another_decorator def process_info(user): ...
-
sensitive_post_parameters
( * параметры ) ¶ Если какое-либо из ваших представлений получает объект
HttpRequest
с потенциально конфиденциальной информацией, вы можете предотвратить появление значений этих параметров в отчетах об ошибках с помощью декоратора :paramètres POST
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'], ) ...
В приведенном выше примере значения POST
pass_word
и параметровcredit_card_number
будут скрыты и заменены звездочками (**********
) в представлении запроса в отчете об ошибках, а значение параметраname
будет отображаться.Чтобы всегда скрывать все параметры POST запроса в отчетах об ошибках, не передавайте никаких параметров декоратору
sensitive_post_parameters
:@sensitive_post_parameters() def my_view(request): ...
Все параметры POST систематически скрыты в сообщениях об ошибках для определенных взглядов
django.contrib.auth.views
(login
,password_reset_confirm
,password_change
иadd_view
, а такжеuser_change_password
в управленииauth
) для предотвращения разглашения конфиденциальной информации , таких как пароли.
Пользовательские отчеты об ошибках ¶
Все, что sensitive_variables()
и делает, sensitive_post_parameters()
- это соответственно аннотировать декорированную функцию именами чувствительных переменных и аннотировать объект HttpRequest
именами чувствительных параметров POST, чтобы эта конфиденциальная информация впоследствии могла быть отфильтрована из отчетов при возникновении ошибки. товар. Настоящая фильтрация выполняется фильтром отчетов об ошибках Django по умолчанию django.views.debug.SafeExceptionReporterFilter
. Этот фильтр использует аннотации декораторов для замены соответствующих значений звездочками ( **********
) при создании отчета об ошибке. Если вы хотите переопределить или настроить это поведение по умолчанию для всего сайта, вам необходимо определить свой собственный класс фильтра и указать Django использовать его с помощью параметра DEFAULT_EXCEPTION_REPORTER_FILTER
:
DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter'
Вы также можете более тонко управлять фильтром, который следует использовать в представлении данных, установив атрибут exception_reporter_filter
объекта HttpRequest
.
def my_view(request):
if request.user.is_authenticated:
request.exception_reporter_filter = CustomExceptionReporterFilter()
...
Ваш настраиваемый класс фильтра должен наследовать
django.views.debug.SafeExceptionReporterFilter
и переопределять следующие атрибуты и методы:
-
класс
SafeExceptionReporterFilter
¶ -
cleansed_substitute
¶ - Новое в Django 3.1.
Строковое значение, на которое нужно заменить конфиденциальное значение. По умолчанию он заменяет значения чувствительных переменных звездочками (
**********
).
- Новое в Django 3.1.
Скомпилированный объект регулярного выражения, используемый для сопоставления параметров и
request.META
значений, считающихся конфиденциальными. По умолчанию эквивалент:import re re.compile(r'API|TOKEN|KEY|SECRET|PASS|SIGNATURE', flags=re.IGNORECASE)
-
is_active
( запрос ) ¶ Возврат
True
для активации фильтрации вget_post_parameters()
иget_traceback_frame_variables()
. По умолчанию фильтр активен, еслиDEBUG
естьFalse
. Обратите внимание, что чувствительныеrequest.META
значения всегда фильтруются вместе со значениями чувствительных настроек, как описано вDEBUG
документации.
-
get_post_parameters
( запрос ) ¶ Возвращает отфильтрованный словарь параметров POST. Чувствительные значения заменяются на
cleansed_substitute
.
-
get_traceback_frame_variables
( запрос , tb_frame ) ¶ Возвращает отфильтрованный словарь локальных переменных для заданного кадра трассировки. Чувствительные значения заменяются на
cleansed_substitute
.
-
Если вам необходимо настроить отчеты об ошибках помимо фильтрации, вы можете указать собственный класс репортера ошибок, определив
DEFAULT_EXCEPTION_REPORTER
параметр:
DEFAULT_EXCEPTION_REPORTER = 'path.to.your.CustomExceptionReporter'
Репортер исключений отвечает за компиляцию данных отчета об исключениях и соответствующее форматирование их как текста или HTML. (Репортер исключений использует
DEFAULT_EXCEPTION_REPORTER_FILTER
при подготовке данных отчета об исключениях.)
Ваш собственный класс репортера должен быть унаследован от
django.views.debug.ExceptionReporter
.
-
класс
ExceptionReporter
¶ -
get_traceback_data
() ¶ Вернуть словарь, содержащий информацию о трассировке.
Это основная точка расширения для настройки отчетов об исключениях, например:
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
() ¶ Вернуть HTML-версию отчета об исключении.
Используется для HTML-версии страницы ошибки HTTP отладки 500.
-
get_traceback_text
() ¶ Вернуть текстовую версию отчета об исключении.
Используется для текстовой версии страницы ошибок HTTP отладки 500 и отчетов по электронной почте.
-
Как и в случае с классом фильтра, вы можете контролировать, какой класс репортера исключений использовать в любом данном представлении, установив атрибут HttpRequest
's
exception_reporter_class
:
def my_view(request):
if request.user.is_authenticated:
request.exception_reporter_class = CustomExceptionReporter()
...
Смотрите также
Также возможно настроить отчеты об ошибках, написав соответствующее промежуточное ПО для исключения . В этом случае рекомендуется имитировать встроенную в Django обработку ошибок и уведомлять об ошибках только в том случае, если DEBUG
есть False
.