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

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

Если эти условия соблюдены, 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.

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

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
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