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

При работе с общедоступным сайтом всегда следует выключать настройку DEBUG. Это значительно ускорит работу сервера и предотвратит доступ злоумышленников к информации о вашем приложении, которая может быть раскрыта страницами ошибок.

Однако, если DEBUG установлено в значение False, вы никогда не увидите ошибки, генерируемые вашим сайтом – все увидят только общедоступные страницы ошибок. Вам необходимо отслеживать ошибки, возникающие на развернутых сайтах, поэтому Django можно настроить для создания отчетов с подробной информацией об этих ошибках.

Отчеты по электронной почте

Ошибки сервера

Когда DEBUG равно False, Django будет отправлять электронные письма пользователям, указанным в настройке ADMINS, всякий раз, когда ваш код вызывает необработанное исключение и приводит к внутренней ошибке сервера (строго говоря, для любого ответа с кодом состояния HTTP 500 или выше). Это предоставляет администраторам мгновенное уведомление о любых ошибках. Настройка ADMINS получит описание ошибки, полный traceback Python и подробности о запросе HTTP, который вызвал ошибку.

По умолчанию Django будет отправлять письма от root@localhost. Однако некоторые поставщики почтовых услуг отклоняют все письма с этого адреса. Для использования другого адреса отправителя измените настройку SERVER_EMAIL.

Для активации этого поведения поместите адреса получателей в настройку ADMINS.

Ошибки 404

Django также можно настроить для отправки писем об ошибках по неработающим ссылкам (ошибки 404 «страница не найдена»). Django отправляет письма об ошибках 404, когда:

• DEBUG равно False;
• Настройка MIDDLEWARE включает django.middleware.common.BrokenLinkEmailsMiddleware.

Если эти условия выполнены, Django отправит электронные письма пользователям, указанным в настройке MANAGERS, всякий раз, когда ваш код вызывает ошибку 404, и у запроса есть referer. Он не беспокоится об отправке писем для 404 с отсутствующим referer – это обычно просто люди, вводящие неработающие URL-адреса или неисправленные веб-боты. Он также игнорирует 404, когда referer равен запрошенному URL, так как это поведение характерно для неисправленных веб-ботов.

Вы можете указать 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 (например, игнорировать запросы от веб-роботов), вы должны наследоваться от него и переопределить его методы.

Фильтрация отчетов об ошибках

Фильтрация конфиденциальной информации

Отчеты об ошибках очень полезны для отладки ошибок, поэтому в общем случае полезно записывать как можно больше релевантной информации об этих ошибках. Например, по умолчанию Django записывает полный стек вызовов для поднятого исключения, локальные переменные каждого кадра стека вызовов и HttpRequest’s атрибуты.

Однако иногда определенные типы информации могут быть слишком конфиденциальными и, следовательно, не должны отслеживаться, например, пароль пользователя или номер кредитной карты. Поэтому помимо фильтрации настроек, которые, как представляется, являются конфиденциальными, как описано в документации DEBUG, Django предлагает набор декораторов функций, которые помогут вам контролировать, какая информация должна быть отфильтрована из отчетов об ошибках в рабочей среде (то есть, когда DEBUG установлено в значение False): sensitive_variables() и sensitive_post_parameters().

sensitive_variables(*variables) [source]

Если функция (вид или любой обычный обратный вызов) в вашем коде использует локальные переменные, которые могут содержать конфиденциальную информацию, вы можете предотвратить включение значений этих переменных в отчеты об ошибках с помощью декоратора 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(*parameters) [source]

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

Настраиваемые отчёты об ошибках

Все 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'

Вы также можете более точно управлять тем, какой фильтр использовать в конкретном представлении, установив атрибут HttpRequest объекта exception_reporter_filter:

def my_view(request):
    if request.user.is_authenticated:
        request.exception_reporter_filter = CustomExceptionReporterFilter()
    ...

Ваш пользовательский класс фильтра должен наследовать от django.views.debug.SafeExceptionReporterFilter и может переопределить следующие методы:

class SafeExceptionReporterFilter [source]

SafeExceptionReporterFilter.is_active(request) [source]

Возвращает True для активации фильтрации, выполняемой в других методах. По умолчанию фильтр активен, если DEBUG имеет значение False.

SafeExceptionReporterFilter.get_post_parameters(request) [source]

Возвращает отфильтрованный словарь параметров POST. По умолчанию он заменяет значения конфиденциальных параметров звёздочками (**********).

SafeExceptionReporterFilter.get_traceback_frame_variables(request, tb_frame) [source]

Возвращает отфильтрованный словарь локальных переменных для данного кадра трассировки. По умолчанию он заменяет значения конфиденциальных переменных звёздочками (**********).