Настройки

ABSOLUTE_URL_OVERRIDES

По умолчанию: {} (пустой словарь)

Словарь, сопоставляющий строки "app_label.model_name" функциям, которые принимают объект модели и возвращают его URL. Это способ добавления или переопределения методов get_absolute_url() отдельно для каждой установки. Пример:

ABSOLUTE_URL_OVERRIDES = {
    "blogs.blog": lambda o: "/blogs/%s/" % o.slug,
    "news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
}

Имя модели, используемое в этой настройке, должно быть записано строчными буквами независимо от регистра букв в имени фактического класса модели.

ADMINS

По умолчанию: [] (пустой список)

Список всех людей, которым отправляются уведомления об ошибках в коде. Когда DEBUG=False и AdminEmailHandler настроен в LOGGING (настроено по умолчанию), Django отправляет этим людям по электронной почте сведения об исключениях, возникших в цикле обработки запроса и ответа.

Каждый элемент списка должен быть строкой с адресом электронной почты. Пример:

ADMINS = ["john@example.com", '"Ng, Mary" <mary@example.com>']

ALLOWED_HOSTS

По умолчанию: [] (пустой список)

Список строк с именами хостов/доменов, которые может обслуживать этот сайт Django. Это мера безопасности, предотвращающая атаки через HTTP-заголовок Host, возможные даже при многих внешне безопасных конфигурациях веб-сервера.

Значения в этом списке могут быть полными именами (например, 'www.example.com'); в этом случае они будут точно сопоставляться с заголовком Host запроса (без учета регистра, порт не учитывается). Значение, начинающееся с точки, можно использовать как подстановочный шаблон для поддоменов: '.example.com' будет соответствовать example.com, www.example.com и любому другому поддомену example.com. Значение '*' будет соответствовать чему угодно; в этом случае проверку заголовка Host необходимо выполнять самостоятельно (например, в промежуточном ПО; если вы используете такой способ, это промежуточное ПО должно быть указано первым в MIDDLEWARE).

Django также допускает использование полного доменного имени (FQDN) для любых записей. Некоторые браузеры добавляют завершающую точку в заголовок Host, которую Django удаляет при проверке хоста.

Если заголовок Host (или X-Forwarded-Host, если включена настройка USE_X_FORWARDED_HOST) не соответствует ни одному значению в этом списке, метод django.http.HttpRequest.get_host() вызовет исключение SuspiciousOperation.

Если DEBUG имеет значение True, а ALLOWED_HOSTS пуст, хост проверяется на соответствие ['.localhost', '127.0.0.1', '[::1]'].

Настройка ALLOWED_HOSTS также проверяется при запуске тестов.

Эта проверка выполняется только через get_host(); если ваш код обращается непосредственно к заголовку Host из request.META, вы обходите эту защиту.

APPEND_SLASH

По умолчанию: True

Если установлено значение True, URL запроса не соответствует ни одному шаблону в URLconf и не заканчивается косой чертой, выполняется перенаправление HTTP на тот же URL с добавленной косой чертой. Обратите внимание, что при перенаправлении могут быть потеряны данные, отправленные в запросе POST.

Настройка APPEND_SLASH используется только в том случае, если установлено CommonMiddleware (см. промежуточное ПО). См. также PREPEND_WWW.

CACHES

По умолчанию:

{
    "default": {
        "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
    }
}

Словарь, содержащий настройки всех кэшей, используемых Django. Это вложенный словарь, содержимое которого сопоставляет псевдонимы кэшей со словарями, содержащими параметры отдельных кэшей.

Настройка CACHES должна конфигурировать кэш default; также можно указать любое количество дополнительных кэшей. Если вы используете серверную часть кэша, отличную от локального кэша в памяти, или вам нужно определить несколько кэшей, потребуются другие параметры. Доступны следующие параметры кэша.

def make_key(key, key_prefix, version):
    return ":".join([key_prefix, str(version), key])

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": "/var/tmp/django_cache",
    }
}

CACHE_MIDDLEWARE_ALIAS

По умолчанию: 'default'

Подключение кэша, используемое промежуточным ПО кэширования.

CACHE_MIDDLEWARE_KEY_PREFIX

По умолчанию: '' (пустая строка)

Строка, добавляемая в начало ключей кэша, создаваемых промежуточным ПО кэширования. Этот префикс объединяется с настройкой KEY_PREFIX, а не заменяет ее.

См. систему кэширования Django.

CACHE_MIDDLEWARE_SECONDS

По умолчанию: 600

Целое число — количество секунд, в течение которых промежуточное ПО кэширования будет кэшировать страницу по умолчанию.

См. систему кэширования Django.

CSRF_COOKIE_AGE

По умолчанию: 31449600 (примерно 1 год в секундах)

Срок действия CSRF-файлов cookie в секундах.

Длительный срок действия задается, чтобы избежать проблем, если пользователь закроет браузер или добавит страницу в закладки, а затем загрузит ее из кэша браузера. Без постоянных файлов cookie отправка формы в этом случае завершилась бы ошибкой.

Некоторые браузеры (в частности, Internet Explorer) могут запрещать использование постоянных файлов cookie или повреждать на диске индексы хранилища файлов cookie, из-за чего проверки защиты CSRF могут (иногда периодически) завершаться ошибкой. Измените эту настройку на None, чтобы использовать сеансовые CSRF-файлы cookie, которые хранятся в памяти, а не в постоянном хранилище.

CSRF_COOKIE_DOMAIN

По умолчанию: None

Домен, используемый при установке CSRF-файла cookie. Это может быть полезно, чтобы легко разрешить запросы между поддоменами, исключив их из стандартной защиты от подделки межсайтовых запросов. Здесь следует указать строку, например ".example.com", чтобы разрешить POST-запрос из формы на одном поддомене для представления, обслуживаемого с другого поддомена.

Обратите внимание, что наличие этой настройки не означает, что защита Django от CSRF по умолчанию защищена от атак между поддоменами. См. раздел ограничения CSRF.

CSRF_COOKIE_HTTPONLY

По умолчанию: False

Следует ли использовать флаг HttpOnly для CSRF-файла cookie. Если задано значение True, клиентский JavaScript не сможет получить доступ к CSRF-файлу cookie.

Обозначение CSRF-файла cookie как HttpOnly не обеспечивает практической защиты, поскольку CSRF предназначена только для защиты от атак между доменами. Если злоумышленник может прочитать файл cookie с помощью JavaScript, то, с точки зрения браузера, он уже находится в том же домене и в любом случае может делать все, что захочет. (Уязвимость XSS гораздо опаснее CSRF.)

Хотя эта настройка практически не дает преимуществ, иногда ее требуют аудиторы безопасности.

Если вы включили эту настройку и вам нужно отправлять значение CSRF-токена с AJAX-запросом, JavaScript должен получать значение из скрытого поля формы с CSRF-токеном, а не из файла cookie.

Сведения о HttpOnly см. в описании SESSION_COOKIE_HTTPONLY.

CSRF_COOKIE_NAME

По умолчанию: 'csrftoken'

Имя файла cookie, используемого для токена аутентификации CSRF. Оно может быть любым, если отличается от имен других файлов cookie в вашем приложении. См. защиту от подделки межсайтовых запросов.

CSRF_COOKIE_PATH

По умолчанию: '/'

Путь, задаваемый для CSRF-файла cookie. Он должен совпадать с путем URL вашей установки Django или быть родительским путем.

Это полезно, если у вас запущено несколько экземпляров Django с одним и тем же именем хоста. Для них можно задать разные пути файлов cookie, и каждый экземпляр будет видеть только свой CSRF-файл cookie.

CSRF_COOKIE_SAMESITE

По умолчанию: 'Lax'

Значение флага SameSite для CSRF-файла cookie. Этот флаг предотвращает отправку файла cookie в межсайтовых запросах.

Сведения о SameSite см. в описании SESSION_COOKIE_SAMESITE.

CSRF_COOKIE_SECURE

По умолчанию: False

Следует ли использовать защищенный файл cookie для CSRF. Если задано значение True, файл cookie будет помечен как «защищенный», а это означает, что браузеры могут гарантировать его отправку только через HTTPS-соединение.

CSRF_USE_SESSIONS

По умолчанию: False

Следует ли хранить CSRF-токен в сеансе пользователя вместо файла cookie. Для этого требуется использовать django.contrib.sessions.

Хранить CSRF-токен в файле cookie (значение по умолчанию в Django) безопасно, однако в других веб-фреймворках распространено хранение токена в сеансе, поэтому аудиторы безопасности иногда требуют именно такой подход.

Поскольку представления ошибок по умолчанию требуют CSRF-токен, SessionMiddleware должно располагаться в MIDDLEWARE перед любым промежуточным ПО, которое может вызвать исключение и запустить представление ошибки (например, PermissionDenied), если вы используете CSRF_USE_SESSIONS. См. порядок промежуточного ПО.

CSRF_FAILURE_VIEW

По умолчанию: 'django.views.csrf.csrf_failure'

Путь через точки к функции-представлению, используемой при отклонении входящего запроса защитой CSRF. Функция должна иметь следующую сигнатуру:

def csrf_failure(request, reason=""): ...

где reason — короткое сообщение (предназначенное для разработчиков или журналирования, а не для конечных пользователей), указывающее причину отклонения запроса. Функция должна возвращать объект HttpResponseForbidden.

django.views.csrf.csrf_failure() принимает дополнительный параметр template_name, значение которого по умолчанию — '403_csrf.html'. Если существует шаблон с таким именем, он будет использован для отображения страницы.

CSRF_HEADER_NAME

По умолчанию: 'HTTP_X_CSRFTOKEN'

Имя заголовка запроса, используемого для аутентификации CSRF.

Как и другие HTTP-заголовки в request.META, имя заголовка, полученное от сервера, нормализуется: все символы преобразуются в верхний регистр, дефисы заменяются символами подчеркивания, а к имени добавляется префикс 'HTTP_'. Например, если клиент отправляет заголовок 'X-XSRF-TOKEN', значение настройки должно быть 'HTTP_X_XSRF_TOKEN'.

CSRF_TRUSTED_ORIGINS

По умолчанию: [] (пустой список)

Список доверенных источников для небезопасных запросов (например, POST).

Для запросов, содержащих заголовок Origin, защита Django от CSRF требует, чтобы этот заголовок соответствовал источнику, указанному в заголовке Host.

Для небезопасного запроса secure, не содержащего заголовок Origin, запрос должен иметь заголовок Referer, соответствующий источнику, указанному в заголовке Host.

Эти проверки предотвращают, например, успешное выполнение запроса POST с subdomain.example.com к api.example.com. Если вам нужны междоменные небезопасные запросы, продолжая этот пример, добавьте 'https://subdomain.example.com' в этот список (и/или http://..., если запросы поступают с незащищенной страницы).

Настройка также поддерживает поддомены, поэтому, например, можно добавить 'https://*.example.com', чтобы разрешить доступ со всех поддоменов example.com.

DATABASES

По умолчанию: {} (пустой словарь)

Словарь, содержащий настройки всех баз данных, используемых в Django. Это вложенный словарь, в котором каждому псевдониму базы данных соответствует словарь с параметрами отдельной базы данных.

Настройка DATABASES должна задавать базу данных default; также можно указать любое количество дополнительных баз данных.

Самый простой файл настроек предназначен для конфигурации с одной базой данных SQLite. Его можно настроить следующим образом:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": "mydatabase",
    }
}

Для подключения к другим серверным системам баз данных, таким как MariaDB, MySQL, Oracle или PostgreSQL, потребуются дополнительные параметры подключения. О том, как указать другие типы баз данных, см. настройку ENGINE ниже. Этот пример предназначен для PostgreSQL:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": "mydatabase",
        "USER": "mydatabaseuser",
        "PASSWORD": "mypassword",
        "HOST": "127.0.0.1",
        "PORT": "5432",
    }
}

Доступны следующие дополнительные параметры, которые могут понадобиться для более сложных конфигураций:

"HOST": "/var/run/mysql"

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "USER": "mydatabaseuser",
        "NAME": "mydatabase",
        "TEST": {
            "NAME": "mytestdatabase",
        },
    },
}

DATA_UPLOAD_MAX_MEMORY_SIZE

По умолчанию: 2621440 (то есть 2,5 МБ).

Максимальный размер тела запроса в байтах. Если он превышен, возникает исключение SuspiciousOperation (RequestDataTooBig). Проверка выполняется при обращении к request.body или request.POST; при расчёте учитывается общий размер запроса без данных загружаемых файлов. Чтобы отключить проверку, можно задать значение None. Приложениям, ожидающим необычно большие отправки форм, следует настроить этот параметр.

Объём данных запроса связан с объёмом памяти, необходимым для его обработки и заполнения словарей GET и POST. Если не ограничивать размер запросов, их можно использовать для атаки типа «отказ в обслуживании». Поскольку веб-серверы обычно не выполняют углублённую проверку запросов, аналогичную проверку на этом уровне провести невозможно.

См. также FILE_UPLOAD_MAX_MEMORY_SIZE.

DATA_UPLOAD_MAX_NUMBER_FIELDS

По умолчанию: 1000

Максимальное количество параметров, которые можно получить через GET или POST. Если оно превышено, возникает исключение SuspiciousOperation (TooManyFields). Чтобы отключить проверку, можно задать значение None. Приложениям, ожидающим необычно большое количество полей формы, следует настроить этот параметр.

Количество параметров запроса связано со временем, необходимым для его обработки и заполнения словарей GET и POST. Если не ограничивать размер запросов, их можно использовать для атаки типа «отказ в обслуживании». Поскольку веб-серверы обычно не выполняют углублённую проверку запросов, аналогичную проверку на этом уровне провести невозможно.

DATA_UPLOAD_MAX_NUMBER_FILES

По умолчанию: 100

Максимальное количество файлов, которые можно получить через POST в запросе с кодировкой multipart/form-data. Если оно превышено, возникает исключение SuspiciousOperation (TooManyFiles). Чтобы отключить проверку, можно задать значение None. Приложениям, ожидающим необычно большое количество файловых полей, следует настроить этот параметр.

Количество принимаемых файлов связано со временем и объёмом памяти, необходимыми для обработки запроса. Если не ограничивать размер запросов, их можно использовать для атаки типа «отказ в обслуживании». Поскольку веб-серверы обычно не выполняют углублённую проверку запросов, аналогичную проверку на этом уровне провести невозможно.

DATABASE_ROUTERS

По умолчанию: [] (пустой список)

Список маршрутизаторов, определяющих, какую базу данных использовать при выполнении запроса к базе данных.

См. документацию об автоматической маршрутизации баз данных в конфигурациях с несколькими базами данных.

DATE_FORMAT

По умолчанию: 'N j, Y' (например, Feb. 4, 2003)

Формат по умолчанию для отображения полей даты в любой части системы. Обратите внимание: формат, заданный для текущей локали, имеет более высокий приоритет и будет использоваться вместо него. См. allowed date format strings.

См. также DATETIME_FORMAT, TIME_FORMAT и SHORT_DATE_FORMAT.

DATE_INPUT_FORMATS

По умолчанию:

[
    "%Y-%m-%d",  # '2006-10-25'
    "%m/%d/%Y",  # '10/25/2006'
    "%m/%d/%y",  # '10/25/06'
    "%b %d %Y",  # 'Oct 25 2006'
    "%b %d, %Y",  # 'Oct 25, 2006'
    "%d %b %Y",  # '25 Oct 2006'
    "%d %b, %Y",  # '25 Oct, 2006'
    "%B %d %Y",  # 'October 25 2006'
    "%B %d, %Y",  # 'October 25, 2006'
    "%d %B %Y",  # '25 October 2006'
    "%d %B, %Y",  # '25 October, 2006'
]

Список форматов, принимаемых при вводе данных в поле даты. Форматы проверяются по порядку; используется первый подходящий. Обратите внимание: в этих строках формата применяется синтаксис модуля datetime Python, а не строки формата фильтра шаблонов date.

Формат, заданный для текущей локали, имеет более высокий приоритет и будет использоваться вместо него.

См. также DATETIME_INPUT_FORMATS и TIME_INPUT_FORMATS.

DATETIME_FORMAT

По умолчанию: 'N j, Y, P' (например, Feb. 4, 2003, 4 p.m.)

Формат по умолчанию для отображения полей даты и времени в любой части системы. Обратите внимание: формат, заданный для текущей локали, имеет более высокий приоритет и будет использоваться вместо него. См. allowed date format strings.

См. также DATE_FORMAT, TIME_FORMAT и SHORT_DATETIME_FORMAT.

DATETIME_INPUT_FORMATS

По умолчанию:

[
    "%Y-%m-%d %H:%M:%S",  # '2006-10-25 14:30:59'
    "%Y-%m-%d %H:%M:%S.%f",  # '2006-10-25 14:30:59.000200'
    "%Y-%m-%d %H:%M",  # '2006-10-25 14:30'
    "%m/%d/%Y %H:%M:%S",  # '10/25/2006 14:30:59'
    "%m/%d/%Y %H:%M:%S.%f",  # '10/25/2006 14:30:59.000200'
    "%m/%d/%Y %H:%M",  # '10/25/2006 14:30'
    "%m/%d/%y %H:%M:%S",  # '10/25/06 14:30:59'
    "%m/%d/%y %H:%M:%S.%f",  # '10/25/06 14:30:59.000200'
    "%m/%d/%y %H:%M",  # '10/25/06 14:30'
]

Список форматов, принимаемых при вводе данных в поле даты и времени. Форматы проверяются по порядку; используется первый подходящий. Обратите внимание: в этих строках формата применяется синтаксис модуля datetime Python, а не строки формата фильтра шаблонов date. Форматы только для даты не включены, поскольку поля даты и времени в крайнем случае автоматически используют DATE_INPUT_FORMATS.

Формат, заданный для текущей локали, имеет более высокий приоритет и будет использоваться вместо него.

См. также DATE_INPUT_FORMATS и TIME_INPUT_FORMATS.

DEBUG

По умолчанию: False

Логическое значение, включающее или отключающее режим отладки.

Никогда не развёртывайте сайт в рабочей среде с включённой настройкой DEBUG.

Одна из основных особенностей режима отладки — отображение подробных страниц ошибок. Если приложение вызывает исключение, когда DEBUG имеет значение True, Django покажет подробную трассировку стека, включая множество метаданных о вашей среде, например все текущие настройки Django (из settings.py).

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

• 'API'
• 'KEY'
• 'PASS'
• 'SECRET'
• 'SIGNATURE'
• 'TOKEN'

Обратите внимание, что это частичные совпадения. 'PASS' совпадёт и с PASSWORD, так же как 'TOKEN' совпадёт с TOKENIZED и так далее.

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

Также важно помнить, что при включённой настройке DEBUG Django сохраняет каждый выполненный SQL-запрос. Это полезно при отладке, но в рабочей среде быстро приведёт к значительному расходу памяти.

Наконец, если DEBUG имеет значение False, необходимо также правильно настроить параметр ALLOWED_HOSTS. В противном случае на все запросы будет возвращён ответ «Bad Request (400)».

DEBUG_PROPAGATE_EXCEPTIONS

По умолчанию: False

Если задано значение True, Django пропускает обработку исключений функций представлений (handler500 или отладочное представление, если DEBUG имеет значение True) и регистрацию ответов с кодом 500 (django.request); исключения передаются выше по стеку вызовов.

Это может быть полезно в некоторых конфигурациях тестирования. Не следует использовать эту настройку на работающем сайте, если только вы не хотите, чтобы ответы «Internal Server Error» формировал веб-сервер, а не Django. В этом случае убедитесь, что сервер не показывает в ответе трассировку стека и другие конфиденциальные сведения.

DECIMAL_SEPARATOR

По умолчанию: '.' (точка)

Разделитель десятичной части, используемый по умолчанию при форматировании десятичных чисел.

Обратите внимание: формат, заданный локалью, имеет более высокий приоритет и будет применен вместо него.

См. также NUMBER_GROUPING, THOUSAND_SEPARATOR и USE_THOUSAND_SEPARATOR.

DEFAULT_AUTO_FIELD

По умолчанию: 'django.db.models.BigAutoField'

Тип поля первичного ключа по умолчанию для моделей, в которых нет поля с параметром primary_key=True.

DEFAULT_CHARSET

По умолчанию: 'utf-8'

Кодировка по умолчанию для всех объектов HttpResponse, если тип MIME не указан вручную. Используется при формировании заголовка Content-Type.

DEFAULT_EXCEPTION_REPORTER

По умолчанию: 'django.views.debug.ExceptionReporter'

Класс средства формирования отчетов об исключениях по умолчанию, используемый, если он еще не назначен экземпляру HttpRequest. См. раздел Пользовательские отчеты об ошибках.

DEFAULT_EXCEPTION_REPORTER_FILTER

По умолчанию: 'django.views.debug.SafeExceptionReporterFilter'

Класс фильтра средства формирования отчетов об исключениях по умолчанию, используемый, если он еще не назначен экземпляру HttpRequest. См. раздел Фильтрация отчетов об ошибках.

DEFAULT_FROM_EMAIL

По умолчанию: 'webmaster@localhost'

Адрес электронной почты по умолчанию для автоматической переписки от имени администратора сайта. Этот адрес используется в заголовке From: исходящих писем и может быть указан в любом формате, допустимом для выбранного протокола отправки почты.

Это не влияет на сообщения об ошибках, отправляемые адресатам ADMINS и MANAGERS. Для этого см. SERVER_EMAIL.

DEFAULT_INDEX_TABLESPACE

По умолчанию: '' (пустая строка)

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

DEFAULT_TABLESPACE

По умолчанию: '' (пустая строка)

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

DISALLOWED_USER_AGENTS

По умолчанию: [] (пустой список)

Список скомпилированных объектов регулярных выражений, соответствующих строкам User-Agent, которым запрещено посещать любые страницы сайта. Используйте этот параметр для ботов и поисковых роботов. Он используется только при установленном CommonMiddleware (см. раздел Промежуточное ПО).

EMAIL_BACKEND

По умолчанию: 'django.core.mail.backends.smtp.EmailBackend'

Серверная часть для отправки электронных писем. Список доступных серверных частей см. в разделе Серверные части электронной почты.

EMAIL_FILE_PATH

По умолчанию: не задано

Каталог, используемый файловой серверной частью электронной почты для хранения выходных файлов.

EMAIL_HOST

По умолчанию: 'localhost'

Узел, используемый для отправки электронной почты.

См. также EMAIL_PORT.

EMAIL_HOST_PASSWORD

По умолчанию: '' (пустая строка)

Пароль для SMTP-сервера, заданного в EMAIL_HOST. Этот параметр используется вместе с EMAIL_HOST_USER для аутентификации на SMTP-сервере. Если один из этих параметров не задан, Django не будет пытаться выполнить аутентификацию.

См. также EMAIL_HOST_USER.

EMAIL_HOST_USER

По умолчанию: '' (пустая строка)

Имя пользователя для SMTP-сервера, заданного в EMAIL_HOST. Если оно не задано, Django не будет пытаться выполнить аутентификацию.

См. также EMAIL_HOST_PASSWORD.

EMAIL_PORT

По умолчанию: 25

Порт SMTP-сервера, заданного в EMAIL_HOST.

EMAIL_SUBJECT_PREFIX

По умолчанию: '[Django] '

Префикс темы писем, отправляемых с помощью django.core.mail.mail_admins или django.core.mail.mail_managers. Скорее всего, вам понадобится добавить пробел в конце.

EMAIL_USE_LOCALTIME

По умолчанию: False

Определяет, нужно ли указывать заголовок SMTP Date в сообщениях электронной почты в местном часовом поясе (True) или в UTC (False).

EMAIL_USE_TLS

По умолчанию: False

Определяет, следует ли использовать TLS-соединение (защищенное соединение) при взаимодействии с SMTP-сервером. Этот параметр используется для явных TLS-соединений, обычно через порт 587. Если соединение зависает, см. параметр неявного TLS EMAIL_USE_SSL.

EMAIL_USE_SSL

По умолчанию: False

Определяет, следует ли использовать неявное TLS-соединение (защищенное соединение) при взаимодействии с SMTP-сервером. В большинстве руководств по электронной почте этот тип TLS-соединения называется SSL. Обычно он используется через порт 465. Если возникли проблемы, см. параметр явного TLS EMAIL_USE_TLS.

Обратите внимание: EMAIL_USE_TLS и EMAIL_USE_SSL взаимоисключающие, поэтому установите значение True только для одного из этих параметров.

EMAIL_SSL_CERTFILE

По умолчанию: None

Если для EMAIL_USE_SSL или EMAIL_USE_TLS задано значение True и для защищенного соединения с SMTP-сервером требуется аутентификация клиента, укажите с помощью этого параметра путь к файлу цепочки сертификатов в формате PEM. Его необходимо использовать вместе с EMAIL_SSL_KEYFILE.

Не следует использовать EMAIL_SSL_CERTFILE с самоподписанным сертификатом сервера или сертификатом от частного центра сертификации (CA). В таких случаях сертификат сервера (или корневой сертификат частного CA) следует установить в системное хранилище CA. Это можно сделать, следуя инструкциям для конкретной платформы по установке корневого сертификата CA, или использовать переменные среды OpenSSL SSL_CERT_FILE либо SSL_CERT_DIR для указания пользовательского хранилища сертификатов (если изменение системного хранилища невозможно или нежелательно).

Для более сложных сценариев можно унаследовать SMTP-класс EmailBackend и добавить корневые сертификаты в его ssl_context с помощью ssl.SSLContext.load_verify_locations().

EMAIL_SSL_KEYFILE

По умолчанию: None

Если для EMAIL_USE_SSL или EMAIL_USE_TLS задано значение True, можно дополнительно указать путь к файлу закрытого ключа в формате PEM для аутентификации клиента при SSL-соединении. Используйте его вместе с EMAIL_SSL_CERTFILE.

Обратите внимание: установка EMAIL_SSL_CERTFILE и EMAIL_SSL_KEYFILE не приводит к проверке сертификата. Эти значения передаются базовому SSL-соединению. Подробную информацию об обработке файла цепочки сертификатов и файла закрытого ключа см. в документации к функции ssl.SSLContext.wrap_socket() из Python.

EMAIL_TIMEOUT

По умолчанию: None

Задает время ожидания в секундах для блокирующих операций, например попытки подключения.

FILE_UPLOAD_HANDLERS

По умолчанию:

[
    "django.core.files.uploadhandler.MemoryFileUploadHandler",
    "django.core.files.uploadhandler.TemporaryFileUploadHandler",
]

Список обработчиков для загрузки файлов. Изменение этого параметра позволяет полностью настроить или даже заменить процесс загрузки файлов в Django.

Подробности см. в разделе Управление файлами.

FILE_UPLOAD_MAX_MEMORY_SIZE

По умолчанию: 2621440 (т. е. 2,5 МБ).

Максимальный размер (в байтах), до достижения которого загруженный файл хранится в памяти, прежде чем его содержимое начнет передаваться в файловую систему. Подробности см. в разделе Управление файлами.

См. также DATA_UPLOAD_MAX_MEMORY_SIZE.

FILE_UPLOAD_DIRECTORY_PERMISSIONS

По умолчанию: None

Числовой режим доступа для каталогов, создаваемых в процессе загрузки файлов.

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

Этот параметр работает аналогично параметру FILE_UPLOAD_PERMISSIONS и имеет те же ограничения.

FILE_UPLOAD_PERMISSIONS

По умолчанию: 0o644

Числовой режим (т. е. 0o644), устанавливаемый для недавно загруженных файлов. Подробнее о значении этих режимов см. в документации к os.chmod().

Если задано значение None, поведение зависит от операционной системы. На большинстве платформ временные файлы будут иметь режим 0o600, а файлы, сохраненные из памяти, будут записаны с использованием стандартной системной маски umask.

По соображениям безопасности эти разрешения не применяются к временным файлам, хранящимся в каталоге FILE_UPLOAD_TEMP_DIR.

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

FILE_UPLOAD_TEMP_DIR

По умолчанию: None

Каталог для временного хранения данных (обычно файлов размером больше FILE_UPLOAD_MAX_MEMORY_SIZE) во время загрузки файлов. Если задано значение None, Django будет использовать стандартный временный каталог операционной системы. Например, в Unix-подобных операционных системах по умолчанию используется /tmp.

Подробности см. в разделе Управление файлами.

FIRST_DAY_OF_WEEK

По умолчанию: 0 (воскресенье)

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

Значение должно быть целым числом от 0 до 6, где 0 означает воскресенье, 1 — понедельник и т. д.

FIXTURE_DIRS

По умолчанию: [] (пустой список)

Список каталогов для поиска файлов фикстур в порядке поиска, помимо каталога fixtures каждого приложения.

Обратите внимание: эти пути следует указывать с прямыми косыми чертами в стиле Unix, даже в Windows.

См. разделы Предоставление данных с помощью фикстур и Загрузка фикстур.

FORCE_SCRIPT_NAME

По умолчанию: None

Если значение не равно None, оно будет использоваться в качестве значения переменной окружения SCRIPT_NAME для любого HTTP-запроса. Этот параметр позволяет переопределить предоставленное сервером значение SCRIPT_NAME, которое может быть переписанной версией предпочтительного значения или вообще отсутствовать. Кроме того, django.setup() использует этот параметр для задания префикса скрипта для преобразователя URL вне цикла запрос-ответ (например, в командах управления и автономных скриптах), чтобы формировать правильные URL, когда задано значение FORCE_SCRIPT_NAME.

FORM_RENDERER

По умолчанию: 'django.forms.renderers.DjangoTemplates'

Класс, отображающий формы и виджеты форм. Он должен реализовывать низкоуровневый API отображения. В Django входят следующие средства отображения форм:

• 'django.forms.renderers.DjangoTemplates'
• 'django.forms.renderers.Jinja2'
• 'django.forms.renderers.TemplatesSetting'

FORMAT_MODULE_PATH

По умолчанию: None

Полный путь Python к пакету, содержащему пользовательские определения форматов для локалей проекта. Если значение не равно None, Django будет искать файл formats.py в каталоге с именем текущей локали и использовать форматы, определенные в этом файле.

Ожидается, что имя каталога с определениями форматов будет записано в нотации имени локали, например de, pt_BR, en_US и т. д.

Например, если для FORMAT_MODULE_PATH задано значение mysite.formats, а текущий язык — en (английский), Django будет ожидать следующую структуру каталогов:

mysite/
    formats/
        __init__.py
        en/
            __init__.py
            formats.py

В качестве значения этого параметра также можно задать список путей Python, например:

FORMAT_MODULE_PATH = [
    "mysite.formats",
    "some_app.formats",
]

При поиске определенного формата Django будет перебирать все указанные пути Python, пока не найдет модуль, в котором этот формат действительно определен. Это означает, что форматы, определенные в пакетах, расположенных выше в списке, будут иметь приоритет над такими же форматами в пакетах ниже.

Доступны следующие форматы:

• DATE_FORMAT
• DATE_INPUT_FORMATS
• DATETIME_FORMAT,
• DATETIME_INPUT_FORMATS
• DECIMAL_SEPARATOR
• FIRST_DAY_OF_WEEK
• MONTH_DAY_FORMAT
• NUMBER_GROUPING
• SHORT_DATE_FORMAT
• SHORT_DATETIME_FORMAT
• THOUSAND_SEPARATOR
• TIME_FORMAT
• TIME_INPUT_FORMATS
• YEAR_MONTH_FORMAT

IGNORABLE_404_URLS

По умолчанию: [] (пустой список)

Список скомпилированных объектов регулярных выражений, описывающих URL, которые следует игнорировать при отправке по электронной почте уведомлений об ошибках HTTP 404 (см. раздел Управление сообщениями об ошибках). Регулярные выражения сопоставляются с результатом request's full paths (включая строку запроса, если она есть). Используйте этот параметр, если на вашем сайте отсутствует часто запрашиваемый файл, например favicon.ico или robots.txt.

Этот параметр используется только при включенном BrokenLinkEmailsMiddleware (см. раздел Промежуточное ПО).

INSTALLED_APPS

По умолчанию: [] (пустой список)

Список строк, обозначающих все приложения, включенные в эту установку Django. Каждая строка должна представлять собой точечный путь Python к:

• классу конфигурации приложения (предпочтительный вариант) или
• пакету, содержащему приложение.

Подробнее о конфигурациях приложений.

Если несколько приложений предоставляют разные версии одного и того же ресурса (шаблона, статического файла, команды управления или перевода), приоритет имеет приложение, указанное в INSTALLED_APPS первым.

INTERNAL_IPS

По умолчанию: [] (пустой список)

Список IP-адресов в виде строк, которые:

• Позволяют контекстному процессору debug() добавлять переменные в контекст шаблона.
• Позволяют использовать букмарклеты admindocs, даже если пользователь не вошел в систему как сотрудник.
• Помечаются как «внутренние» (в отличие от «ВНЕШНИЕ») в письмах AdminEmailHandler.

LANGUAGE_CODE

По умолчанию: 'en-us'

Строка, представляющая код языка для этой установки. Он должен соответствовать стандартному формату идентификатора языка. Например, американский английский — "en-us". См. также список идентификаторов языков и раздел Интернационализация и локализация.

У этого параметра три назначения:

• Если промежуточное ПО локали не используется, параметр определяет, какой перевод будет показан всем пользователям.
• Если промежуточное ПО локали активно, параметр задаёт резервный язык на случай, если не удаётся определить предпочтительный язык пользователя или сайт его не поддерживает. Он также задаёт резервный перевод, если для некоторой строки нет перевода на предпочтительный язык пользователя.
• Если локализация явно отключена с помощью фильтра unlocalize или тега {% localize off %}, параметр задаёт резервные форматы локализации, которые будут применены вместо неё. Подробности см. в разделе управление локализацией в шаблонах.

Подробнее см. в разделе Как Django определяет языковые предпочтения.

LANGUAGE_COOKIE_AGE

По умолчанию: None (истекает при закрытии браузера)

Срок действия языковой cookie в секундах.

LANGUAGE_COOKIE_DOMAIN

По умолчанию: None

Домен, используемый для языковой cookie. Для междоменных cookie укажите строку, например "example.com", или используйте None для обычной доменной cookie.

Будьте осторожны при изменении этого параметра на рабочем сайте. Если вы измените его, чтобы включить междоменные cookie на сайте, где ранее использовались обычные доменные cookie, существующие cookie пользователей со старым доменом не будут обновлены. В результате пользователи сайта не смогут переключать язык, пока эти cookie не истекут. Единственный безопасный и надёжный способ выполнить переход — навсегда изменить имя языковой cookie (с помощью параметра LANGUAGE_COOKIE_NAME) и добавить промежуточное ПО, которое скопирует значение из старой cookie в новую, а затем удалит старую.

LANGUAGE_COOKIE_HTTPONLY

По умолчанию: False

Следует ли использовать флаг HttpOnly для языковой cookie. Если задано значение True, клиентский JavaScript не сможет получить доступ к языковой cookie.

Подробнее о HttpOnly см. в разделе SESSION_COOKIE_HTTPONLY.

LANGUAGE_COOKIE_NAME

По умолчанию: 'django_language'

Имя cookie, используемой в качестве языковой cookie. Можно указать любое имя (если оно отличается от имён других cookie в приложении). См. раздел Интернационализация и локализация.

LANGUAGE_COOKIE_PATH

По умолчанию: '/'

Путь, заданный для языковой cookie. Он должен совпадать с путём URL вашей установки Django или быть родительским для этого пути.

Это полезно, если под одним именем хоста запущено несколько экземпляров Django. Они могут использовать разные пути cookie, и каждый экземпляр будет видеть только собственную языковую cookie.

Будьте осторожны при изменении этого параметра на рабочем сайте. Если вы измените его, указав более глубокий путь, существующие cookie пользователей со старым путём не будут обновлены. В результате пользователи сайта не смогут переключать язык, пока эти cookie не истекут. Единственный безопасный и надёжный способ выполнить переход — навсегда изменить имя языковой cookie (с помощью параметра LANGUAGE_COOKIE_NAME) и добавить промежуточное ПО, которое скопирует значение из старой cookie в новую, а затем удалит старую.

LANGUAGE_COOKIE_SAMESITE

По умолчанию: None

Значение флага SameSite языковой cookie. Этот флаг не позволяет отправлять cookie в межсайтовых запросах.

Подробнее о SameSite см. в разделе SESSION_COOKIE_SAMESITE.

LANGUAGE_COOKIE_SECURE

По умолчанию: False

Следует ли использовать защищённую cookie для языковой cookie. Если задано значение True, cookie будет помечена как «защищённая», то есть браузеры могут гарантировать, что она отправляется только через HTTPS-соединение.

LANGUAGES

По умолчанию: список всех доступных языков. Этот список постоянно растёт, поэтому его копия здесь неизбежно быстро устарела бы. Актуальный список переведённых языков можно найти в файле django/conf/global_settings.py.

Список состоит из 2-кортежей формата (код языка, language name), например ('ja', 'Japanese'). Он определяет, какие языки доступны для выбора. См. раздел Интернационализация и локализация.

Как правило, значения по умолчанию достаточно. Задавайте этот параметр, только если хотите ограничить выбор языков подмножеством языков, предоставляемых Django.

Если вы определяете пользовательский параметр LANGUAGES, можно пометить названия языков как строки для перевода с помощью функции gettext_lazy().

Пример файла настроек:

from django.utils.translation import gettext_lazy as _

LANGUAGES = [
    ("de", _("German")),
    ("en", _("English")),
]

LANGUAGES_BIDI

По умолчанию: список всех кодов языков, для которых используется письмо справа налево. Актуальный список таких языков можно найти в файле django/conf/global_settings.py.

Список содержит коды языков, для которых используется письмо справа налево.

Как правило, значения по умолчанию достаточно. Задавайте этот параметр, только если хотите ограничить выбор языков подмножеством языков, предоставляемых Django. Если вы определяете пользовательский параметр LANGUAGES, список двунаправленных языков может содержать коды языков, которые не включены на данном сайте.

LOCALE_PATHS

По умолчанию: [] (пустой список)

Список каталогов, в которых Django ищет файлы переводов. См. раздел Как Django находит переводы.

Пример:

LOCALE_PATHS = [
    "/home/www/project/common_files/locale",
    "/var/local/translations/locale",
]

Django будет искать в каждом из этих путей каталоги <locale_code>/LC_MESSAGES, содержащие файлы переводов.

LOGGING

По умолчанию: словарь конфигурации ведения журнала.

Структура данных, содержащая сведения о конфигурации. Если эта структура данных не пуста, её содержимое будет передано в качестве аргумента методу настройки, описанному в параметре LOGGING_CONFIG.

В частности, конфигурация ведения журнала по умолчанию отправляет ошибки HTTP 500 обработчику электронной почты, когда параметр DEBUG имеет значение False. См. также раздел Настройка ведения журнала.

Конфигурацию ведения журнала по умолчанию можно посмотреть в файле django/utils/log.py.

LOGGING_CONFIG

По умолчанию: 'logging.config.dictConfig'

Путь к вызываемому объекту, который будет использоваться для настройки ведения журнала в проекте Django. По умолчанию указывает на метод настройки dictConfig из Python.

Если присвоить параметру LOGGING_CONFIG значение None, процесс настройки ведения журнала будет пропущен.

MANAGERS

По умолчанию: [] (пустой список)

Список в том же формате, что и ADMINS, который указывает, кому отправлять уведомления о неработающих ссылках, если включено BrokenLinkEmailsMiddleware.

MEDIA_ROOT

По умолчанию: '' (пустая строка)

Абсолютный путь в файловой системе к каталогу, в котором будут храниться файлы, загруженные пользователями.

Пример: "/var/www/example.com/media/"

См. также MEDIA_URL.

MEDIA_URL

По умолчанию: '' (пустая строка)

URL для обработки медиафайлов, предоставляемых из MEDIA_ROOT и используемых для управления сохранёнными файлами. Если значение не пустое, оно должно оканчиваться косой чертой. Вам потребуется настроить обслуживание этих файлов как в среде разработки, так и в рабочей среде.

Чтобы использовать {{ MEDIA_URL }} в шаблонах, добавьте 'django.template.context_processors.media' в параметр 'context_processors' настройки TEMPLATES.

Пример: "https://media.example.com/"

MIDDLEWARE

По умолчанию: None

Список используемого промежуточного ПО. См. раздел Промежуточное ПО.

MIGRATION_MODULES

По умолчанию: {} (пустой словарь)

Словарь, указывающий пакет, в котором находятся модули миграций для каждого приложения. Значение этого параметра по умолчанию — пустой словарь, но стандартное имя пакета для модулей миграций — migrations.

Пример:

{"blog": "blog.db_migrations"}

В этом случае миграции приложения blog будут находиться в пакете blog.db_migrations.

Если передать аргумент app_label, команда makemigrations автоматически создаст пакет, если он ещё не существует.

Если указать None в качестве значения для приложения, Django будет считать это приложение приложением без миграций, даже если существует подмодуль migrations. Это можно использовать, например, в файле тестовых настроек, чтобы пропустить миграции во время тестирования (таблицы для моделей приложений всё равно будут созданы). Чтобы отключить миграции для всех приложений во время тестирования, вместо этого можно присвоить параметру MIGRATE значение False. Если MIGRATION_MODULES используется в общих настройках проекта, не забудьте применить параметр migrate --run-syncdb, если хотите создать таблицы для приложения.

MONTH_DAY_FORMAT

По умолчанию: 'F j'

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

Например, при фильтрации списка изменений в административном интерфейсе Django по дате с помощью иерархического фильтра заголовок для конкретного дня отображает день и месяц. В разных локалях используются разные форматы. Например, в американском английском будет «January 1», а в испанском может быть «1 Enero».

Обратите внимание: формат, заданный локалью, имеет более высокий приоритет и будет применён вместо этого.

См. allowed date format strings. См. также DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT и YEAR_MONTH_FORMAT.

NUMBER_GROUPING

По умолчанию: 0

Количество цифр в каждой группе целой части числа.

Обычно это используется для отображения разделителя тысяч. Если значением этого параметра является 0, группировка числа не выполняется. Если значение больше 0, в качестве разделителя групп будет использоваться THOUSAND_SEPARATOR.

В некоторых локалях используются группы цифр неодинакового размера, например 10,00,00,000 в en_IN. В этом случае можно передать последовательность с размерами групп цифр. Первое число задаёт размер группы перед десятичным разделителем, а каждое последующее — размер предыдущих групп. Если последовательность заканчивается на -1, дальнейшая группировка не выполняется. Если последовательность заканчивается на 0, размер последней группы используется для оставшейся части числа.

Пример кортежа для en_IN:

NUMBER_GROUPING = (3, 2, 0)

Обратите внимание: формат, заданный локалью, имеет более высокий приоритет и будет применён вместо этого.

См. также DECIMAL_SEPARATOR, THOUSAND_SEPARATOR и USE_THOUSAND_SEPARATOR.

PREPEND_WWW

По умолчанию: False

Следует ли добавлять поддомен «www.» к URL, в которых его нет. Этот параметр используется только в том случае, если установлено CommonMiddleware (см. раздел Промежуточное ПО). См. также APPEND_SLASH.

ROOT_URLCONF

По умолчанию: не определено

Строка, представляющая полный путь импорта Python к корневому URLconf, например "mydjangoapps.urls". Для отдельного запроса значение можно переопределить, задав атрибут urlconf входящего объекта HttpRequest. Подробности см. в разделе Как Django обрабатывает запрос.

SECRET_KEY

По умолчанию: '' (пустая строка)

Секретный ключ для конкретной установки Django. Он используется для обеспечения криптографической подписи и должен иметь уникальное, непредсказуемое значение.

django-admin startproject автоматически добавляет случайно сгенерированный SECRET_KEY в каждый новый проект.

При использовании ключа не следует предполагать, что он имеет тип текста или байтов. Для преобразования к нужному типу при каждом использовании следует вызывать force_str() или force_bytes().

Django откажется запускаться, если параметр SECRET_KEY не задан.

Секретный ключ используется для:

• Всех сеансов, если используется любой серверный модуль сеансов, отличный от django.contrib.sessions.backends.cache, либо используется стандартный get_session_auth_hash().
• Всех сообщений, если используется CookieStorage или FallbackStorage.
• Всех токенов PasswordResetView.
• Любого использования криптографической подписи, если не предоставлен другой ключ.

Если секретный ключ больше не задан в параметре SECRET_KEY и не содержится в SECRET_KEY_FALLBACKS, всё перечисленное выше будет аннулировано. При смене секретного ключа временно переместите старый ключ в SECRET_KEY_FALLBACKS. Секретные ключи не используются для паролей пользователей, поэтому смена ключа на них не повлияет.

SECRET_KEY_FALLBACKS

По умолчанию: []

Список резервных секретных ключей для конкретной установки Django. Они используются для обеспечения смены SECRET_KEY.

Чтобы сменить секретные ключи, задайте новый SECRET_KEY и переместите предыдущее значение в начало списка SECRET_KEY_FALLBACKS. Когда будете готовы завершить срок действия сеансов, токенов сброса пароля и прочих данных, использующих эти ключи, удалите старые значения из конца списка SECRET_KEY_FALLBACKS.

При использовании значений секретных ключей не следует предполагать, что они имеют тип текста или байтов. Для преобразования к нужному типу при каждом использовании следует вызывать force_str() или force_bytes().

SECURE_CONTENT_TYPE_NOSNIFF

По умолчанию: True

Если значение True, SecurityMiddleware устанавливает заголовок X-Content-Type-Options: nosniff для всех ответов, в которых он ещё не задан.

SECURE_CROSS_ORIGIN_OPENER_POLICY

По умолчанию: 'same-origin'

Если значение не равно None, SecurityMiddleware устанавливает во всех ответах, в которых он ещё не задан, заголовок Cross-Origin Opener Policy со значением, указанным в параметре.

SECURE_CSP

По умолчанию: {}

Этот параметр задаёт директивы, используемые промежуточным ПО ContentSecurityPolicyMiddleware, которое формирует и добавляет заголовок Content-Security-Policy (CSP) ко всем ответам, в которых он ещё не задан.

Заголовок Content-Security-Policy предписывает браузерам ограничивать ресурсы, которые может загружать страница. Правильно настроенная CSP может блокировать содержимое, нарушающее заданные правила, помогая предотвращать межсайтовый скриптинг (XSS) и другие атаки с внедрением содержимого благодаря явному указанию доверенных источников для таких данных, как скрипты, стили, изображения, шрифты и другие ресурсы.

Значением параметра должно быть отображение (обычно словарь), сопоставляющее имена директив с их значениями. Каждый ключ должен быть допустимой директивой CSP, например default-src или script-src. Соответствующее значение может быть списком, кортежем или множеством выражений источников либо URL, разрешённых для этой директивы. Если используется множество, оно будет автоматически отсортировано для обеспечения единообразного вывода в создаваемых заголовках.

В этом примере показана ожидаемая структура с использованием констант, определённых в разделе Константы CSP:

from django.utils.csp import CSP

SECURE_CSP = {
    "default-src": [CSP.SELF],
    "img-src": ["data:", CSP.SELF, "https://images.example.com"],
    "frame-src": [CSP.NONE],
}

SECURE_CSP_REPORT_ONLY

По умолчанию: {}

Эта настройка аналогична SECURE_CSP, но вместо применения политики она указывает ContentSecurityPolicyMiddleware добавлять к ответам заголовок Content-Security-Policy-Report-Only, который позволяет браузерам отслеживать нарушения политики и отправлять отчёты о них, не блокируя содержимое. Это полезно для тестирования и доработки политики перед её применением.

Большинство браузеров регистрируют нарушения CSP в консоли разработчика и могут отправлять их на конечную точку для отчётов. Чтобы собирать эти отчёты, необходимо определить директиву report-uri (подробности см. в разделе Отчёты о нарушениях политики).

Как отмечено в документации MDN по Content-Security-Policy-Report-Only, для отправки отчётов необходимо указать директиву report-uri; в противном случае заголовок не будет влиять на отправку отчётов (за исключением записи сообщений в консоль инструментов разработчика браузера).

В соответствии с примером настройки SECURE_CSP:

from django.utils.csp import CSP

SECURE_CSP_REPORT_ONLY = {
    "default-src": [CSP.SELF],
    "img-src": ["data:", CSP.SELF, "https://images.example.com"],
    "frame-src": [CSP.NONE],
    "report-uri": "/my-site/csp/reports/",
}

SECURE_HSTS_INCLUDE_SUBDOMAINS

По умолчанию: False

Если True, SecurityMiddleware добавляет директиву includeSubDomains в заголовок HTTP Strict Transport Security. Это не действует, если SECURE_HSTS_SECONDS не установлена в ненулевое значение.

SECURE_HSTS_PRELOAD

По умолчанию: False

Если True, SecurityMiddleware добавляет директиву preload в заголовок HTTP Strict Transport Security. Это не действует, если SECURE_HSTS_SECONDS не установлена в ненулевое значение.

SECURE_HSTS_SECONDS

По умолчанию: 0

Если установлено ненулевое целочисленное значение, SecurityMiddleware добавляет заголовок HTTP Strict Transport Security ко всем ответам, в которых он ещё не установлен.

SECURE_PROXY_SSL_HEADER

По умолчанию: None

Кортеж, представляющий сочетание HTTP-заголовка и значения, которое указывает на защищённость запроса. Это определяет поведение метода is_secure() объекта запроса.

По умолчанию is_secure() определяет, является ли запрос защищённым, проверяя, что в запрошенном URL используется https://. Этот метод важен для защиты Django от CSRF-атак и может использоваться в вашем коде или сторонних приложениях.

Однако если ваше приложение Django работает за прокси-сервером, прокси может скрывать, использовался ли HTTPS в исходном запросе. Если соединение между прокси и Django не защищено HTTPS, is_secure() всегда будет возвращать False — даже для запросов, отправленных конечным пользователем по HTTPS. И наоборот, если соединение между прокси и Django защищено HTTPS, is_secure() всегда будет возвращать True — даже для запросов, изначально отправленных по HTTP.

В этой ситуации настройте прокси так, чтобы он задавал пользовательский HTTP-заголовок, сообщающий Django, был ли запрос получен по HTTPS, и установите SECURE_PROXY_SSL_HEADER, чтобы Django знал, какой заголовок проверять.

Укажите кортеж из двух элементов — имени заголовка и требуемого значения. Например:

SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

Эта настройка указывает Django доверять заголовку X-Forwarded-Proto, полученному от нашего прокси, и считать запрос гарантированно защищённым (то есть изначально полученным по HTTPS), если:

• значение заголовка равно 'https' или
• его начальное, самое левое значение равно 'https' в случае списка протоколов, разделённых запятыми (например, 'https,http,http').

Устанавливайте эту настройку только в том случае, если вы контролируете свой прокси или имеете другие гарантии того, что он корректно задаёт и удаляет этот заголовок.

Обратите внимание: формат заголовка должен соответствовать формату, используемому в request.META: все буквы заглавные, и, вероятно, имя начинается с HTTP_. (Помните, что Django автоматически добавляет 'HTTP_' в начало имён x-заголовков, прежде чем сделать заголовок доступным в request.META.)

SECURE_REDIRECT_EXEMPT

По умолчанию: [] (пустой список)

Если путь URL соответствует регулярному выражению из этого списка, запрос не будет перенаправлен на HTTPS. SecurityMiddleware удаляет начальные косые черты из путей URL, поэтому шаблоны не должны их содержать, например SECURE_REDIRECT_EXEMPT = [r'^no-ssl/$', …]. Если SECURE_SSL_REDIRECT равно False, эта настройка не действует.

SECURE_REFERRER_POLICY

По умолчанию: 'same-origin'

Если настройка задана, SecurityMiddleware устанавливает для заголовка Referrer Policy указанное значение во всех ответах, в которых этот заголовок ещё не задан.

SECURE_SSL_HOST

По умолчанию: None

Если задана строка (например, secure.example.com), все перенаправления SSL будут вести на этот хост, а не на хост исходного запроса (например, www.example.com). Если SECURE_SSL_REDIRECT равно False, эта настройка не действует.

SECURE_SSL_REDIRECT

По умолчанию: False

Если True, SecurityMiddleware перенаправляет все запросы, не использующие HTTPS, на HTTPS (за исключением URL, соответствующих регулярным выражениям из SECURE_REDIRECT_EXEMPT).

SERIALIZATION_MODULES

По умолчанию: не задано

Словарь модулей, содержащих определения сериализаторов (в виде строк), с идентификаторами типов сериализации в виде строк в качестве ключей. Например, чтобы определить сериализатор YAML, используйте:

SERIALIZATION_MODULES = {"yaml": "path.to.yaml_serializer"}

SERVER_EMAIL

По умолчанию: 'root@localhost'

Адрес электронной почты, с которого отправляются сообщения об ошибках, например сообщения для ADMINS и MANAGERS. Этот адрес используется в заголовке From: и может быть указан в любом формате, допустимом для выбранного протокола отправки почты.

SHORT_DATE_FORMAT

По умолчанию: 'm/d/Y' (например, 12/31/2003)

Доступный формат, который можно использовать для отображения полей даты в шаблонах. Обратите внимание: формат, заданный локалью, имеет более высокий приоритет и будет применён вместо него. См. allowed date format strings.

См. также DATE_FORMAT и SHORT_DATETIME_FORMAT.

SHORT_DATETIME_FORMAT

По умолчанию: 'm/d/Y P' (например, 12/31/2003 4 p.m.)

Доступный формат, который можно использовать для отображения полей даты и времени в шаблонах. Обратите внимание: формат, заданный локалью, имеет более высокий приоритет и будет применён вместо него. См. allowed date format strings.

См. также DATE_FORMAT и SHORT_DATE_FORMAT.

SIGNING_BACKEND

По умолчанию: 'django.core.signing.TimestampSigner'

Бэкенд, используемый для подписывания файлов cookie и других данных.

См. также документацию по криптографической подписи.

SILENCED_SYSTEM_CHECKS

По умолчанию: [] (пустой список)

Список идентификаторов сообщений, созданных системой проверок (то есть ["models.W001"]), которые вы хотите навсегда принять и игнорировать. Результаты отключённых проверок не будут выводиться в консоль.

См. также документацию по системе проверок.

STORAGES

По умолчанию:

{
    "default": {
        "BACKEND": "django.core.files.storage.FileSystemStorage",
    },
    "staticfiles": {
        "BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage",
    },
}

Словарь, содержащий настройки всех хранилищ, используемых Django. Это вложенный словарь, в котором псевдоним хранилища сопоставляется со словарём параметров отдельного хранилища.

Для хранилищ можно выбрать любые псевдонимы. Однако два псевдонима имеют особое значение:

• default для управления файлами. 'django.core.files.storage.FileSystemStorage' — это механизм хранения по умолчанию.
• staticfiles для управления статическими файлами. 'django.contrib.staticfiles.storage.StaticFilesStorage' — это механизм хранения по умолчанию.

Ниже приведён пример settings.py, определяющий пользовательское файловое хранилище под названием example:

STORAGES = {
    # ...
    "example": {
        "BACKEND": "django.core.files.storage.FileSystemStorage",
        "OPTIONS": {
            "location": "/example",
            "base_url": "/example/",
        },
    },
}

OPTIONS передаются в BACKEND при инициализации в **kwargs.

Готовый экземпляр бэкенда хранилища можно получить из django.core.files.storage.storages. Используйте ключ, соответствующий определению бэкенда в STORAGES.

TASKS

По умолчанию:

{
    "default": {
        "BACKEND": "django.tasks.backends.immediate.ImmediateBackend",
    }
}

Словарь, содержащий настройки всех бэкендов задач, используемых Django. Это вложенный словарь, в котором псевдонимы бэкендов сопоставляются со словарём параметров каждого бэкенда.

Настройка TASKS должна задавать бэкенд default; также можно указать любое количество дополнительных бэкендов. В зависимости от используемого бэкенда могут потребоваться другие параметры. Стандартно доступны следующие параметры.

TEMPLATES

По умолчанию: [] (пустой список)

Список, содержащий настройки всех обработчиков шаблонов, используемых Django. Каждый элемент списка — это словарь с параметрами отдельного обработчика.

Ниже приведена конфигурация, указывающая обработчику шаблонов Django загружать шаблоны из подкаталога templates каждого установленного приложения:

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "APP_DIRS": True,
    },
]

Следующие параметры доступны для всех бэкендов.

TEST_RUNNER

По умолчанию: 'django.test.runner.DiscoverRunner'

Имя класса, используемого для запуска набора тестов. См. раздел Использование других сред тестирования.

TEST_NON_SERIALIZED_APPS

По умолчанию: [] (пустой список)

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

Это увеличивает время запуска тестового исполнителя. Если вы знаете, что некоторым приложениям эта возможность не нужна, укажите здесь их полные имена (например, 'django.contrib.contenttypes'), чтобы исключить их из процесса сериализации.

THOUSAND_SEPARATOR

По умолчанию: ',' (запятая)

Разделитель разрядов по умолчанию, используемый при форматировании чисел. Эта настройка используется, только если USE_THOUSAND_SEPARATOR равно True, а значение NUMBER_GROUPING больше 0.

Обратите внимание: формат, заданный локалью, имеет более высокий приоритет и будет применён вместо него.

См. также NUMBER_GROUPING, DECIMAL_SEPARATOR и USE_THOUSAND_SEPARATOR.

TIME_FORMAT

По умолчанию: 'P' (например, 4 p.m.)

Формат по умолчанию для отображения полей времени в любой части системы. Обратите внимание: формат, заданный локалью, имеет более высокий приоритет и будет применён вместо него. См. allowed date format strings.

См. также DATE_FORMAT и DATETIME_FORMAT.

TIME_INPUT_FORMATS

По умолчанию:

[
    "%H:%M:%S",  # '14:30:59'
    "%H:%M:%S.%f",  # '14:30:59.000200'
    "%H:%M",  # '14:30'
]

Список форматов, принимаемых при вводе данных в поле времени. Форматы проверяются по порядку; используется первый подходящий. Обратите внимание: эти строки формата используют синтаксис модуля datetime Python, а не строки формата фильтра шаблонов date.

Формат, заданный локалью, имеет более высокий приоритет и будет применён вместо него.

См. также DATE_INPUT_FORMATS и DATETIME_INPUT_FORMATS.

TIME_ZONE

По умолчанию: 'America/Chicago'

Строка, обозначающая часовой пояс этой установки. См. список часовых поясов.

Обратите внимание: это не обязательно часовой пояс сервера. Например, один сервер может обслуживать несколько сайтов на Django, каждый со своей настройкой часового пояса.

Если USE_TZ равно False, это часовой пояс, в котором Django будет хранить все значения даты и времени. Если USE_TZ равно True, это часовой пояс по умолчанию, который Django будет использовать для отображения даты и времени в шаблонах и интерпретации введённых в формы значений.

В средах Unix (где реализована функция time.tzset()) Django задаёт переменную os.environ['TZ'] равной часовому поясу, указанному в настройке TIME_ZONE. Поэтому все представления и модели автоматически работают в этом часовом поясе. Однако Django не задаёт переменную среды TZ, если вы используете вариант ручной конфигурации, описанный в разделе ручная настройка параметров. Если Django не задаёт переменную среды TZ, вы должны сами обеспечить правильную конфигурацию среды для своих процессов.

USE_I18N

По умолчанию: True

Логическое значение, указывающее, должна ли быть включена система переводов Django. Эта настройка позволяет отключить её для повышения производительности. Если установлено значение False, Django выполнит некоторые оптимизации и не будет загружать средства перевода.

См. также LANGUAGE_CODE и USE_TZ.

USE_THOUSAND_SEPARATOR

По умолчанию: False

Логическое значение, указывающее, следует ли отображать числа с разделителем разрядов. Если установлено значение True, Django форматирует числа с использованием настроек NUMBER_GROUPING и THOUSAND_SEPARATOR. На последние две настройки также может влиять локаль, которая имеет приоритет.

См. также DECIMAL_SEPARATOR, NUMBER_GROUPING и THOUSAND_SEPARATOR.

USE_TZ

По умолчанию: True

Логическое значение, указывающее, должны ли значения даты и времени по умолчанию учитывать часовой пояс. Если установлено значение True, Django будет использовать внутри системы значения даты и времени с информацией о часовом поясе.

Если USE_TZ равно False, Django будет использовать наивные значения даты и времени в местном времени, за исключением разбора строк в формате ISO 8601: если в них указана информация о часовом поясе, она всегда сохраняется.

См. также TIME_ZONE и USE_I18N.

USE_X_FORWARDED_HOST

По умолчанию: False

Логическое значение, определяющее, следует ли использовать заголовок X-Forwarded-Host вместо заголовка Host. Эту настройку следует включать только в том случае, если используется прокси, устанавливающий этот заголовок.

Эта настройка имеет приоритет над USE_X_FORWARDED_PORT. Согласно RFC 7239 Section 5.3, заголовок X-Forwarded-Host может содержать номер порта, и в этом случае не следует использовать USE_X_FORWARDED_PORT.

USE_X_FORWARDED_PORT

По умолчанию: False

Логическое значение, определяющее, следует ли использовать заголовок X-Forwarded-Port вместо переменной SERVER_PORT META. Эту настройку следует включать только в том случае, если используется прокси, устанавливающий этот заголовок.

USE_X_FORWARDED_HOST имеет приоритет над этой настройкой.

URLIZE_ASSUME_HTTPS

По умолчанию: False

Установите для этого переходного параметра значение True, чтобы в течение цикла выпусков Django 6.x использовать HTTPS в качестве протокола по умолчанию, если он не указан в URL-адресах, обрабатываемых шаблонными фильтрами urlize и urlizetrunc.

WSGI_APPLICATION

По умолчанию: None

Полный путь Python к объекту WSGI-приложения, который будут использовать встроенные серверы Django (например, runserver). Команда управления django-admin startproject создаст стандартный файл wsgi.py с вызываемым объектом application и укажет этот параметр на этот объект application.

Если параметр не задан, будет использоваться возвращаемое значение django.core.wsgi.get_wsgi_application(). В этом случае поведение runserver будет идентично поведению в предыдущих версиях Django.

YEAR_MONTH_FORMAT

По умолчанию: 'F Y'

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

Например, когда список изменений в административном интерфейсе Django фильтруется с помощью детализации по дате, в заголовке для выбранного месяца отображаются месяц и год. В разных локалях используются разные форматы. Например, в американском английском будет «January 2006», а в другой локали может быть «2006/January».

Обратите внимание, что соответствующий формат, заданный локалью, имеет более высокий приоритет и будет применен вместо этого.

См. allowed date format strings. См. также DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT и MONTH_DAY_FORMAT.

X_FRAME_OPTIONS

По умолчанию: 'DENY'

Значение по умолчанию для заголовка X-Frame-Options, используемого XFrameOptionsMiddleware. См. документацию о защите от кликджекинга.

AUTHENTICATION_BACKENDS

По умолчанию: ['django.contrib.auth.backends.ModelBackend']

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

AUTH_USER_MODEL

По умолчанию: 'auth.User'

Модель, используемая для представления пользователя. См. Замена стандартной модели пользователя.

LOGIN_REDIRECT_URL

По умолчанию: '/accounts/profile/'

URL-адрес или именованный шаблон URL, на который перенаправляются запросы после входа, если у LoginView отсутствует параметр GET next.

LOGIN_URL

По умолчанию: '/accounts/login/'

URL-адрес или именованный шаблон URL, на который перенаправляются запросы для входа при использовании декоратора login_required(), LoginRequiredMixin, AccessMixin или при подключенном LoginRequiredMiddleware.

LOGOUT_REDIRECT_URL

По умолчанию: None

URL-адрес или именованный шаблон URL, на который перенаправляются запросы после выхода, если у LogoutView отсутствует атрибут next_page.

Если задано значение None, перенаправление не выполняется, а отображается представление выхода.

PASSWORD_RESET_TIMEOUT

По умолчанию: 259200 (3 дня, в секундах)

Срок действия ссылки для сброса пароля в секундах.

Используется представлением PasswordResetConfirmView.

PASSWORD_HASHERS

См. Как Django хранит пароли.

По умолчанию:

[
    "django.contrib.auth.hashers.PBKDF2PasswordHasher",
    "django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher",
    "django.contrib.auth.hashers.Argon2PasswordHasher",
    "django.contrib.auth.hashers.BCryptSHA256PasswordHasher",
    "django.contrib.auth.hashers.ScryptPasswordHasher",
]

AUTH_PASSWORD_VALIDATORS

По умолчанию: [] (пустой список)

Список валидаторов, используемых для проверки надежности паролей пользователей. Подробнее см. в разделе Проверка паролей. По умолчанию проверка не выполняется и принимаются любые пароли.

MESSAGE_LEVEL

По умолчанию: messages.INFO

Устанавливает минимальный уровень сообщений, сохраняемых фреймворком сообщений. Подробнее см. в разделе уровни сообщений.

from django.contrib.messages import constants as message_constants

MESSAGE_LEVEL = message_constants.DEBUG

MESSAGE_STORAGE

По умолчанию: 'django.contrib.messages.storage.fallback.FallbackStorage'

Определяет, где Django хранит данные сообщений. Допустимые значения:

• 'django.contrib.messages.storage.fallback.FallbackStorage'
• 'django.contrib.messages.storage.session.SessionStorage'
• 'django.contrib.messages.storage.cookie.CookieStorage'

Подробнее см. в разделе бэкенды хранения сообщений.

Бэкенды, использующие файлы cookie, — CookieStorage и FallbackStorage — при установке файлов cookie используют значения SESSION_COOKIE_DOMAIN, SESSION_COOKIE_SECURE и SESSION_COOKIE_HTTPONLY.

MESSAGE_TAGS

По умолчанию:

{
    messages.DEBUG: "debug",
    messages.INFO: "info",
    messages.SUCCESS: "success",
    messages.WARNING: "warning",
    messages.ERROR: "error",
}

Задает соответствие уровней сообщений тегам сообщений, которые обычно отображаются в HTML как классы CSS. Если указать значение, оно расширит набор значений по умолчанию. Это означает, что нужно указывать только те значения, которые требуется переопределить. Подробнее см. выше в разделе Отображение сообщений.

from django.contrib.messages import constants as message_constants

MESSAGE_TAGS = {message_constants.INFO: ""}

SESSION_CACHE_ALIAS

По умолчанию: 'default'

Если вы используете хранение сеансов в кэше, этот параметр задает используемый кэш.

SESSION_COOKIE_AGE

По умолчанию: 1209600 (2 недели, в секундах)

Срок действия файлов cookie сеанса в секундах.

SESSION_COOKIE_DOMAIN

По умолчанию: None

Домен для файлов cookie сеанса. Для файлов cookie, работающих между доменами, задайте строку, например "example.com", либо используйте None для обычного доменного файла cookie.

Чтобы использовать файлы cookie между доменами вместе с CSRF_USE_SESSIONS, необходимо добавить точку в начале (например, ".example.com"), чтобы проверка referer в промежуточном ПО CSRF работала корректно.

Будьте осторожны при изменении этой настройки на рабочем сайте. Если включить файлы cookie между доменами на сайте, где ранее использовались обычные доменные файлы cookie, существующие файлы cookie пользователей останутся привязанными к старому домену. Пока эти файлы cookie сохраняются, пользователи могут не иметь возможности войти в систему.

Эта настройка также влияет на файлы cookie, устанавливаемые django.contrib.messages.

SESSION_COOKIE_HTTPONLY

По умолчанию: True

Следует ли использовать флаг HttpOnly для файла cookie сеанса. Если установлено значение True, клиентский JavaScript не сможет получить доступ к файлу cookie сеанса.

HttpOnly — это флаг, включаемый в HTTP-заголовок ответа Set-Cookie. Он является частью стандарта файлов cookie RFC 6265 Section 4.1.2.6 и может быть полезен для снижения риска доступа клиентского скрипта к защищенным данным файла cookie.

Это усложняет злоумышленнику использование уязвимости межсайтового скриптинга для полного перехвата сеанса пользователя. Существует мало веских причин отключать эту настройку. Ваш код не должен считывать файлы cookie сеанса из JavaScript.

SESSION_COOKIE_NAME

По умолчанию: 'sessionid'

Имя файла cookie для сеансов. Можно задать любое имя (при условии, что оно отличается от имен других файлов cookie в приложении).

SESSION_COOKIE_PATH

По умолчанию: '/'

Путь, задаваемый для файла cookie сеанса. Он должен совпадать с путем URL-адреса установки Django или быть родительским для него.

Это полезно, если на одном имени хоста работают несколько экземпляров Django. Они могут использовать разные пути файлов cookie, и каждый экземпляр будет видеть только собственный файл cookie сеанса.

SESSION_COOKIE_SAMESITE

По умолчанию: 'Lax'

Значение флага SameSite для файла cookie сеанса. Этот флаг запрещает отправку файла cookie в межсайтовых запросах, тем самым предотвращая CSRF-атаки и делая некоторые способы кражи файла cookie сеанса невозможными.

Допустимые значения настройки:

• 'Strict': запрещает браузеру отправлять файл cookie целевому сайту во всех межсайтовых контекстах просмотра, даже при переходе по обычной ссылке.

  Например, для сайта наподобие GitHub это означает, что если вошедший в систему пользователь перейдет по ссылке на закрытый проект GitHub, размещенной на корпоративном форуме или отправленной по электронной почте, GitHub не получит файл cookie сеанса, и пользователь не сможет получить доступ к проекту. Однако банковский сайт, скорее всего, не захочет разрешать переход на страницы, связанные с транзакциями, с внешних сайтов, поэтому флаг 'Strict' будет уместен.

• 'Lax' (по умолчанию): обеспечивает баланс между безопасностью и удобством использования для сайтов, которым нужно сохранять сеанс входа пользователя после перехода по внешней ссылке.

  В случае с GitHub файл cookie сеанса будет отправляться при переходе по обычной ссылке с внешнего сайта, но будет блокироваться для подверженных CSRF-атакам методов запросов (например, POST).

• 'None' (строка): файл cookie сеанса будет отправляться со всеми одно- и межсайтовыми запросами.
• False: отключает этот флаг.

SESSION_COOKIE_SECURE

По умолчанию: False

Следует ли использовать защищенный файл cookie для сеанса. Если задано значение True, файл cookie будет помечен как «защищенный», что позволяет браузерам гарантировать его отправку только через соединение HTTPS.

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

SESSION_ENGINE

По умолчанию: 'django.contrib.sessions.backends.db'

Определяет, где Django хранит данные сеансов. Доступны следующие встроенные механизмы:

• 'django.contrib.sessions.backends.db'
• 'django.contrib.sessions.backends.file'
• 'django.contrib.sessions.backends.cache'
• 'django.contrib.sessions.backends.cached_db'
• 'django.contrib.sessions.backends.signed_cookies'

Подробнее см. в разделе Настройка механизма сеансов.

SESSION_EXPIRE_AT_BROWSER_CLOSE

По умолчанию: False

Следует ли завершать сеанс, когда пользователь закрывает браузер. См. Сеансы на время работы браузера и постоянные сеансы.

SESSION_FILE_PATH

По умолчанию: None

Если используется хранение сеансов в файлах, этот параметр задает каталог, в котором Django будет хранить данные сеансов. При использовании значения по умолчанию (None) Django будет использовать стандартный временный каталог системы.

SESSION_SAVE_EVERY_REQUEST

По умолчанию: False

Следует ли сохранять данные сеанса при каждом запросе. Если задано значение False (по умолчанию), данные сеанса сохраняются только в случае изменения — то есть если значения в словаре были присвоены или удалены. Пустые сеансы не создаются, даже если эта настройка включена.

SESSION_SERIALIZER

По умолчанию: 'django.contrib.sessions.serializers.JSONSerializer'

Полный путь импорта класса сериализатора, используемого для сериализации данных сеанса. Встроенный сериализатор:

• 'django.contrib.sessions.serializers.JSONSerializer'

Подробнее см. в разделе Сериализация сеансов.

SITE_ID

По умолчанию: не задано

ID текущего сайта в таблице базы данных django_site в виде целого числа. Это позволяет данным приложений быть связанными с определенными сайтами, а одной базе данных — управлять содержимым нескольких сайтов.

STATIC_ROOT

По умолчанию: None

Абсолютный путь к каталогу, в который команда collectstatic собирает статические файлы для развертывания.

Пример: "/var/www/example.com/static/"

Если приложение staticfiles включено (как в стандартном шаблоне проекта), команда управления collectstatic соберет статические файлы в этот каталог. Подробнее об использовании см. в руководстве по управлению статическими файлами.

STATIC_URL

По умолчанию: None

URL-адрес для ссылок на статические файлы, находящиеся в STATIC_ROOT.

Пример: "static/" или "https://static.example.com/"

Если значение не None, оно будет использоваться как базовый путь для определений ресурсов (класс Media) и приложения staticfiles.

Если задано непустое значение, оно должно заканчиваться косой чертой.

Возможно, потребуется настроить раздачу этих файлов в режиме разработки; в рабочей среде это необходимо сделать обязательно.

STATICFILES_DIRS

По умолчанию: [] (пустой список)

Этот параметр определяет дополнительные расположения, которые приложение staticfiles будет обходить, если включено средство поиска FileSystemFinder, например при использовании команды управления collectstatic или findstatic либо представления для раздачи статических файлов.

Здесь следует указать список строк с полными путями к дополнительным каталогам файлов, например:

STATICFILES_DIRS = [
    "/home/special.polls.com/polls/static",
    "/home/polls.com/polls/static",
    "/opt/webfiles/common",
]

Обратите внимание, что для этих путей следует использовать прямые косые черты в стиле Unix, даже в Windows (например, "C:/Users/user/mysite/extra_static_content").

STATICFILES_DIRS = [
    # ...
    ("downloads", "/opt/webfiles/stats"),
]

<a href="{% static 'downloads/polls_20101022.tar.gz' %}">

STATICFILES_FINDERS

По умолчанию:

[
    "django.contrib.staticfiles.finders.FileSystemFinder",
    "django.contrib.staticfiles.finders.AppDirectoriesFinder",
]

Список бэкендов поиска, которые умеют находить статические файлы в различных расположениях.

По умолчанию файлы ищутся в расположениях, заданных в параметре STATICFILES_DIRS (с помощью django.contrib.staticfiles.finders.FileSystemFinder), и в подкаталоге static каждого приложения (с помощью django.contrib.staticfiles.finders.AppDirectoriesFinder). Если найдено несколько файлов с одинаковым именем, используется первый найденный.

Одно средство поиска по умолчанию отключено: django.contrib.staticfiles.finders.DefaultStorageFinder. Если добавить его в параметр STATICFILES_FINDERS, оно будет искать статические файлы в хранилище файлов по умолчанию, заданном ключом default в настройке STORAGES.

Средства поиска статических файлов в настоящее время считаются закрытым интерфейсом, поэтому документация по нему не предоставляется.

Кэш

• CACHES
• CACHE_MIDDLEWARE_ALIAS
• CACHE_MIDDLEWARE_KEY_PREFIX
• CACHE_MIDDLEWARE_SECONDS

База данных

• DATABASES
• DATABASE_ROUTERS
• DEFAULT_INDEX_TABLESPACE
• DEFAULT_TABLESPACE

Отладка

• DEBUG
• DEBUG_PROPAGATE_EXCEPTIONS

Электронная почта

• ADMINS
• DEFAULT_CHARSET
• DEFAULT_FROM_EMAIL
• EMAIL_BACKEND
• EMAIL_FILE_PATH
• EMAIL_HOST
• EMAIL_HOST_PASSWORD
• EMAIL_HOST_USER
• EMAIL_PORT
• EMAIL_SSL_CERTFILE
• EMAIL_SSL_KEYFILE
• EMAIL_SUBJECT_PREFIX
• EMAIL_TIMEOUT
• EMAIL_USE_LOCALTIME
• EMAIL_USE_SSL
• EMAIL_USE_TLS
• MANAGERS
• SERVER_EMAIL

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

• DEFAULT_EXCEPTION_REPORTER
• DEFAULT_EXCEPTION_REPORTER_FILTER
• IGNORABLE_404_URLS
• MANAGERS
• SILENCED_SYSTEM_CHECKS

Загрузка файлов

• FILE_UPLOAD_HANDLERS
• FILE_UPLOAD_MAX_MEMORY_SIZE
• FILE_UPLOAD_PERMISSIONS
• FILE_UPLOAD_TEMP_DIR
• MEDIA_ROOT
• MEDIA_URL
• STORAGES

Формы

• FORM_RENDERER

Глобализация (i18n/l10n)

HTTP

• DATA_UPLOAD_MAX_MEMORY_SIZE
• DATA_UPLOAD_MAX_NUMBER_FIELDS
• DATA_UPLOAD_MAX_NUMBER_FILES
• DEFAULT_CHARSET
• DISALLOWED_USER_AGENTS
• FORCE_SCRIPT_NAME
• INTERNAL_IPS
• MIDDLEWARE

• Безопасность

  • SECURE_CONTENT_TYPE_NOSNIFF
  • SECURE_CROSS_ORIGIN_OPENER_POLICY
  • SECURE_CSP
  • SECURE_CSP_REPORT_ONLY
  • SECURE_HSTS_INCLUDE_SUBDOMAINS
  • SECURE_HSTS_PRELOAD
  • SECURE_HSTS_SECONDS
  • SECURE_PROXY_SSL_HEADER
  • SECURE_REDIRECT_EXEMPT
  • SECURE_REFERRER_POLICY
  • SECURE_SSL_HOST
  • SECURE_SSL_REDIRECT
• SIGNING_BACKEND
• USE_X_FORWARDED_HOST
• USE_X_FORWARDED_PORT
• WSGI_APPLICATION

Ведение журнала

• LOGGING
• LOGGING_CONFIG

Модели

• ABSOLUTE_URL_OVERRIDES
• FIXTURE_DIRS
• INSTALLED_APPS

Безопасность

• Защита от подделки межсайтовых запросов

  • CSRF_COOKIE_DOMAIN
  • CSRF_COOKIE_NAME
  • CSRF_COOKIE_PATH
  • CSRF_COOKIE_SAMESITE
  • CSRF_COOKIE_SECURE
  • CSRF_FAILURE_VIEW
  • CSRF_HEADER_NAME
  • CSRF_TRUSTED_ORIGINS
  • CSRF_USE_SESSIONS
• SECRET_KEY
• SECRET_KEY_FALLBACKS
• URLIZE_ASSUME_HTTPS
• X_FRAME_OPTIONS

Сериализация

• DEFAULT_CHARSET
• SERIALIZATION_MODULES

Шаблоны

• TEMPLATES

Тестирование

• База данных: TEST
• TEST_NON_SERIALIZED_APPS
• TEST_RUNNER

URL-адреса

• APPEND_SLASH
• PREPEND_WWW
• ROOT_URLCONF