Отчет об ошибках ¶
Когда вы запускаете общедоступный сайт, вы всегда должны отключать эту
DEBUG
настройку. Это заставит ваш сервер работать намного быстрее, а также не позволит злоумышленникам увидеть детали вашего приложения, которые могут быть обнаружены на страницах с ошибками.
Тем не менее, работает с DEBUG
набором для False
средств вы никогда не будете видеть ошибки , порождаемые вашего сайта - каждый будет вместо видеть ваши страницы публичных ошибок. Вам необходимо отслеживать ошибки, возникающие на развернутых сайтах, поэтому Django можно настроить для создания отчетов с подробной информацией об этих ошибках.
Отчеты по электронной почте ¶
Ошибки сервера ¶
Когда DEBUG
есть False
, Django отправляет электронное письмо пользователям, указанным в
ADMINS
настройке, всякий раз, когда ваш код вызывает необработанное исключение и приводит к внутренней ошибке сервера (строго говоря, для любого ответа с кодом состояния HTTP 500 или выше). Это дает администраторам немедленное уведомление о любых ошибках. Он ADMINS
получит описание ошибки, полную трассировку Python и подробную информацию о HTTP-запросе, вызвавшем ошибку.
Примечание
Для отправки электронной почты Django требует нескольких настроек, указывающих, как подключаться к вашему почтовому серверу. По крайней мере, вам нужно будет указать EMAIL_HOST
и, возможно,
EMAIL_HOST_USER
и EMAIL_HOST_PASSWORD
, хотя могут потребоваться и другие настройки в зависимости от конфигурации вашего почтового сервера. Обратитесь в Джанго Настройки документации для полного списка параметров электронной почты , связанные с .
По умолчанию Django отправляет электронную почту от root @ localhost . Однако некоторые почтовые провайдеры отклоняют все письма с этого адреса. Чтобы использовать другой адрес отправителя, измените SERVER_EMAIL
настройку.
Чтобы активировать это поведение, укажите в ADMINS
настройках адреса электронной почты получателей
.
Смотрите также
Электронные сообщения об ошибках сервера отправляются с использованием инфраструктуры ведения журнала, поэтому вы можете настроить это поведение, настроив конфигурацию ведения журнала .
404 ошибки ¶
Django также можно настроить на отправку сообщений об ошибках, связанных с неработающими ссылками (ошибка 404 «страница не найдена»). Django отправляет сообщения об ошибке 404 в следующих случаях:
DEBUG
естьFalse
;- Ваша
MIDDLEWARE
настройка включаетdjango.middleware.common.BrokenLinkEmailsMiddleware
.
Если эти условия соблюдены, Django будет отправлять электронное письмо пользователям, указанным в
MANAGERS
настройках, всякий раз, когда ваш код вызывает 404 и у запроса есть реферер. Он не беспокоит отправку электронной почты для сообщений 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 записывает полный отслеживающий за исключением поднятый, каждого TraceBack фрейма «сек локальные переменные, а
HttpRequest
«s атрибуты .
Однако иногда определенные типы информации могут быть слишком конфиденциальными и, следовательно, могут быть неприемлемыми для отслеживания, например, пароль пользователя или номер кредитной карты. Таким образом, помимо фильтрации настроек, которые кажутся чувствительными, как описано в DEBUG
документации, Django предлагает набор декораторов функций, которые помогут вам контролировать, какая информация должна быть отфильтрована из отчетов об ошибках в производственной среде (то есть где
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
объект , который может содержать конфиденциальную информацию, вы можете предотвратить включение значений этих параметров в отчеты об ошибках с помощью декоратора:POST parameters
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'], ) ...
В приведенном выше примере значения параметров
pass_word
иcredit_card_number
POST будут скрыты и заменены звездочками (**********
) в представлении запроса внутри отчетов об ошибках, тогда как значение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
админ) , чтобы предотвратить утечку конфиденциальной информации , такой как пароли пользователей.
Пользовательские отчеты об ошибках ¶
All sensitive_variables()
и sensitive_post_parameters()
do, соответственно, аннотируют декорированную функцию именами конфиденциальных переменных и аннотируют HttpRequest
объект именами конфиденциальных параметров POST, чтобы впоследствии эту конфиденциальную информацию можно было отфильтровать из отчетов при возникновении ошибки. Фактическая фильтрация выполняется репортер фильтром ошибок Джанго по умолчанию:
django.views.debug.SafeExceptionReporterFilter
. Этот фильтр использует аннотации декораторов для замены соответствующих значений звездочками ( **********
) при создании отчетов об ошибках. Если вы хотите переопределить или настроить это поведение по умолчанию для всего вашего сайта, вам необходимо определить свой собственный класс фильтра и указать Django использовать его с помощью
DEFAULT_EXCEPTION_REPORTER_FILTER
параметра:
DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter'
Вы также можете более детально контролировать, какой фильтр использовать в любом заданном представлении, установив
атрибут HttpRequest
's exception_reporter_filter
:
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
¶ -
html_template_path
¶ - Новое в Django 3.2.
Свойство, которое возвращает
pathlib.Path
абсолютный путь файловой системы к шаблону для рендеринга HTML-представления исключения. По умолчанию используется шаблон, предоставленный Django.
-
text_template_path
¶ - Новое в Django 3.2.
Свойство, которое возвращает
pathlib.Path
абсолютный путь файловой системы к шаблону для визуализации текстового представления исключения. По умолчанию используется шаблон, предоставленный Django.
-
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
.