Отчет об ошибках

Когда вы запускаете общедоступный сайт, вы всегда должны отключать эту 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 в следующих случаях:

Если эти условия соблюдены, 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 parameterssensitive_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_numberPOST будут скрыты и заменены звездочками ( **********) в представлении запроса внутри отчетов об ошибках, тогда как значение 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.

Строковое значение, на которое нужно заменить конфиденциальное значение. По умолчанию он заменяет значения чувствительных переменных на звездочки ( **********).

hidden_settings
Новое в 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.

Новое в Django 3.1.

Если вам нужно настроить отчеты об ошибках помимо фильтрации, вы можете указать собственный класс репортера ошибок, определив 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.

Copyright ©2021 All rights reserved