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

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

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

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

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

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

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

Чтобы активировать это поведение, поместите адреса получателей в настройку ADMINS.

Ошибки 404

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

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

Если эти условия выполнены, Django будет отправлять электронные письма пользователям, указанным в настройке MANAGERS, всякий раз, когда ваш код вызывает ошибку 404, и запрос имеет referer. Django не беспокоится об отправке писем для ошибок 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]

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