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

При работе с публичным сайтом всегда следует выключать настройку 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_CLASSES включает django.middleware.common.BrokenLinkEmailsMiddleware.

Если эти условия выполнены, Django будет отправлять электронные письма пользователям, перечисленным в настройке MANAGERS, всякий раз, когда ваш код вызывает ошибку 404, и запрос имеет referer. (Django не беспокоится об отправке сообщений об ошибках 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 записывает полную отладочную информацию для возникшего исключения, каждую кадр отладочной информации’s локальные переменные и HttpRequest’s атрибуты.

Однако иногда определённые типы информации могут быть слишком конфиденциальными и, следовательно, не должны храниться, например, пароль пользователя или номер кредитной карты. Поэтому 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’s 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_request_repr(request)

Возвращает строку представления объекта запроса, то есть значение, которое возвращалось бы repr(request), за исключением того, что используется отфильтрованный словарь параметров POST, определённый методом SafeExceptionReporterFilter.get_post_parameters().

SafeExceptionReporterFilter.get_post_parameters(request) [source]

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

SafeExceptionReporterFilter.get_traceback_frame_variables(request, tb_frame) [source]

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