Настройки¶

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 отправляет этим людям подробную информацию об исключениях, возникших в цикле запрос/ответ.

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

[("John", "john@example.com"), ("Mary", "mary@example.com")]

ALLOWED_HOSTS¶

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

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

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

Django также допускает fully qualified domain name (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 также является checked when running tests.

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

APPEND_SLASH¶

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

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

Настройка APPEND_SLASH используется, только если установлен CommonMiddleware (см. Middleware). См. также 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.

CACHE_MIDDLEWARE_KEY_PREFIX¶

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

Строка, которая будет префиксом к ключам кэша, генерируемым параметром cache middleware. Этот префикс комбинируется с настройкой KEY_PREFIX; он не заменяет ее.

См. Фреймворк кеширования Django.

CACHE_MIDDLEWARE_SECONDS¶

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

Число секунд по умолчанию для кэширования страницы для cache middleware.

См. Фреймворк кеширования Django.

CSRF_COOKIE_AGE¶

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

Возраст CSRF-куки, в секундах.

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

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

CSRF_COOKIE_DOMAIN¶

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

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

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

CSRF_COOKIE_HTTPONLY¶

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

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

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

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

Если вы включили эту функцию и вам нужно отправить значение CSRF-токена с AJAX-запросом, ваш JavaScript должен получить значение from a hidden CSRF token form input вместо from the cookie.

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

CSRF_COOKIE_NAME¶

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

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

CSRF_COOKIE_PATH¶

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

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

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

CSRF_COOKIE_SAMESITE¶

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

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

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

CSRF_COOKIE_SECURE¶

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

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

CSRF_USE_SESSIONS¶

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

Хранить ли CSRF-токен в сессии пользователя, а не в cookie. Это требует использования django.contrib.sessions.

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

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

CSRF_FAILURE_VIEW¶

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

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

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, защита от CSRF в Django требует, чтобы заголовок соответствовал происхождению, указанному в заголовке 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 и рассчитывается по общему размеру запроса, исключая данные загрузки файла. Вы можете установить значение request.POST, чтобы отключить проверку. Приложения, в которых ожидается получение необычно больших сообщений формы, должны настроить этот параметр.

Объем данных запроса соотносится с объемом памяти, необходимой для обработки запроса и заполнения словарей 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¶

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

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

См. документацию по automatic database routing in multi database configurations.

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

Список форматов, которые будут приняты при вводе данных в поле даты. Форматы будут перебираться по порядку, используя первый допустимый. Обратите внимание, что эти строки формата используют Python datetime module syntax, а не строки формата из фильтра шаблона 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'
]

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

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

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

DEBUG¶

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

Булево значение, которое включает/выключает режим отладки.

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

Одной из главных особенностей режима отладки является отображение подробных страниц ошибок. Если ваше приложение вызывает исключение, когда DEBUG равно True, Django отобразит подробный traceback, включая множество метаданных о вашем окружении, например, все текущие определенные настройки 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) пропускается, и исключения распространяются вверх.

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

DECIMAL_SEPARATOR¶

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

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

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

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

DEFAULT_AUTO_FIELD¶

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

Тип поля первичного ключа по умолчанию, используемый для моделей, у которых нет поля с 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 еще не был назначен ни один класс. См. Filtering error reports.

DEFAULT_FILE_STORAGE¶

По умолчанию: 'django.core.files.storage.FileSystemStorage'

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

DEFAULT_FROM_EMAIL¶

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

Адрес электронной почты по умолчанию, который будет использоваться для различной автоматической корреспонденции от менеджера(ов) сайта. Сюда не входят сообщения об ошибках, отправленные на адреса ADMINS и MANAGERS; для этого смотрите SERVER_EMAIL.

DEFAULT_INDEX_TABLESPACE¶

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

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

DEFAULT_TABLESPACE¶

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

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

DISALLOWED_USER_AGENTS¶

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

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

EMAIL_BACKEND¶

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

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

EMAIL_FILE_PATH¶

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

Каталог, используемый file email backend для хранения выходных файлов.

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, вы можете опционально указать путь к файлу цепочки сертификатов в формате PEM, который будет использоваться для SSL-соединения.

EMAIL_SSL_KEYFILE¶

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

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

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

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 будет использовать стандартный временный каталог для данной операционной системы. Например, для операционных систем типа *nix это значение по умолчанию будет /tmp.

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

FIRST_DAY_OF_WEEK¶

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

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

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

FIXTURE_DIRS¶

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

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

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

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

FORCE_SCRIPT_NAME¶

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

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

FORM_RENDERER¶

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

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

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

FORMS_URLFIELD_ASSUME_HTTPS¶

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

Установите этот переходный параметр на True, чтобы отказаться от использования "https" в качестве нового значения по умолчанию URLField.assume_scheme во время цикла выпуска Django 5.x.

FORMAT_MODULE_PATH¶

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

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

Например, если для 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 (см. Middleware).

INSTALLED_APPS¶

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

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

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

Learn more about application configurations.

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

INTERNAL_IPS¶

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

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

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

LANGUAGE_CODE¶

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

Строка, представляющая код языка для данной установки. Он должен быть стандартным language ID format. Например, английский язык США - это "en-us". См. также list of language identifiers и Интернационализация и локализация.

USE_I18N должен быть активен, чтобы эта настройка имела какой-либо эффект.

Он служит двум целям:

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

Более подробную информацию см. в разделе Как Django обнаруживает языковые предпочтения.

LANGUAGE_COOKIE_AGE¶

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

Возраст языкового файла cookie, в секундах.

LANGUAGE_COOKIE_DOMAIN¶

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

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

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

LANGUAGE_COOKIE_HTTPONLY¶

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

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

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

LANGUAGE_COOKIE_NAME¶

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

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

LANGUAGE_COOKIE_PATH¶

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

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

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

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

LANGUAGE_COOKIE_SAMESITE¶

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

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

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

LANGUAGE_COOKIE_SECURE¶

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

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

LANGUAGES¶

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

Список представляет собой список из двух кортежей в формате (language code, 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.

Список содержит language codes для языков, которые пишутся справа налево.

Как правило, значения по умолчанию должно быть достаточно. Устанавливайте этот параметр только в том случае, если вы хотите ограничить выбор языка подмножеством языков, предоставляемых 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. По умолчанию указывает на экземпляр метода конфигурации Python dictConfig.

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

MANAGERS¶

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

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

MEDIA_ROOT¶

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

Абсолютный путь файловой системы к директории, в которой будет храниться user-uploaded files.

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

См. также MEDIA_URL.

MEDIA_URL¶

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

URL, который обрабатывает медиа, обслуживаемые из MEDIA_ROOT, используемый для managing stored files. Он должен заканчиваться слэшем, если задано непустое значение. Вам понадобится configure these files to be served как в среде разработки, так и в среде производства.

Если вы хотите использовать {{ MEDIA_URL }} в своих шаблонах, добавьте 'django.template.context_processors.media' в опцию 'context_processors' в TEMPLATES.

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

MIDDLEWARE¶

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

Список промежуточного программного обеспечения для использования. См. Middleware.

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 фильтруется по дате, в заголовке для определенного дня отображается день и месяц. В разных локалях используются разные форматы. Например, в американском английском будет написано «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 (см. Middleware). См. также APPEND_SLASH.

ROOT_URLCONF¶

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

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

SECRET_KEY¶

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

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

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

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

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

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

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

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

SECRET_KEY_FALLBACKS¶

D

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

I

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

SECURE_HSTS_INCLUDE_SUBDOMAINS¶

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

Если True, SecurityMiddleware добавляет директиву includeSubDomains к заголовку Строгая транспортная безопасность HTTP. Она не имеет эффекта, если только SECURE_HSTS_SECONDS не установлено ненулевое значение.

SECURE_HSTS_PRELOAD¶

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

Если True, SecurityMiddleware добавляет директиву preload к заголовку Строгая транспортная безопасность HTTP. Она не имеет эффекта, если только SECURE_HSTS_SECONDS не установлено ненулевое значение.

SECURE_HSTS_SECONDS¶

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

Если установлено ненулевое целочисленное значение, SecurityMiddleware устанавливает заголовок Строгая транспортная безопасность HTTP на все ответы, которые еще не имеют его.

SECURE_PROXY_SSL_HEADER¶

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

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

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

Однако, если ваше приложение 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-header, прежде чем сделать заголовок доступным в 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 устанавливает заголовок Политика в отношении рефералов во всех ответах, которые еще не имеют его, на указанное значение.

SECURE_SSL_HOST¶

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

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

SECURE_SSL_REDIRECT¶

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

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

SERIALIZATION_MODULES¶

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

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

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

SERVER_EMAIL¶

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

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

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 для managing files. 'django.core.files.storage.FileSystemStorage' - это механизм хранения по умолчанию.
• staticfiles для managing static files. '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.

TEMPLATES¶

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

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

Вот настройка, которая указывает шаблонизатору Django загружать шаблоны из подкаталога templates внутри каждого установленного приложения:

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

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

TEST_RUNNER¶

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

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

TEST_NON_SERIALIZED_APPS¶

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

Для восстановления состояния базы данных между тестами для TransactionTestCases и бэкендов баз данных без транзакций, Django будет serialize the contents of all apps при запуске теста, чтобы затем перезагрузиться из этой копии перед запуском тестов, которым это необходимо.

Это замедляет время запуска программы запуска тестов; если у вас есть приложения, которые, как вы знаете, не нуждаются в этой функции, вы можете добавить их полные имена здесь (например, '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'
]

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

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

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

TIME_ZONE¶

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

Строка, представляющая часовой пояс для данной установки. См. list of time zones.

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

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

В Unix-окружениях (где реализовано time.tzset()), Django устанавливает переменную os.environ['TZ'] в часовой пояс, который вы указали в настройке TIME_ZONE. Таким образом, все ваши представления и модели будут автоматически работать в этом часовом поясе. Однако Django не будет устанавливать переменную окружения TZ, если вы используете опцию ручной настройки, как описано в manually configuring settings. Если 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 имеет приоритет над этой настройкой.

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. См. документацию по clickjacking protection.

AUTHENTICATION_BACKENDS¶

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

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

AUTH_USER_MODEL¶

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

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

LOGIN_REDIRECT_URL¶

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

URL или named URL pattern, куда перенаправляются запросы после входа в систему, когда LoginView не получает next GET-параметр.

LOGIN_URL¶

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

URL или named URL pattern, куда перенаправляются запросы для входа в систему при использовании декоратора login_required(), LoginRequiredMixin или AccessMixin.

LOGOUT_REDIRECT_URL¶

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

URL или named URL pattern, куда перенаправляются запросы после выхода из системы, если 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

Устанавливает минимальный уровень сообщений, который будет записываться фреймворком сообщений. См. раздел message levels для более подробной информации.

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'

Более подробную информацию см. в разделе message storage backends.

Бэкенды, использующие cookies – CookieStorage и FallbackStorage – используют значение SESSION_COOKIE_DOMAIN, SESSION_COOKIE_SECURE и SESSION_COOKIE_HTTPONLY при установке своих cookies.

MESSAGE_TAGS¶

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

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

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

from django.contrib.messages import constants as message_constants

MESSAGE_TAGS = {message_constants.INFO: ""}

SESSION_CACHE_ALIAS¶

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

Если вы используете cache-based session storage, это выбирает кэш для использования.

SESSION_COOKIE_AGE¶

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

Возраст сессионных файлов cookie, в секундах.

SESSION_COOKIE_DOMAIN¶

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

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

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

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

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

SESSION_COOKIE_HTTPONLY¶

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

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

HttpOnly - это флаг, включенный в заголовок ответа Set-Cookie HTTP. Он является частью стандарта 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 для сессионного файла cookie. Если установлено значение True, cookie будет помечен как «безопасный», что означает, что браузеры могут гарантировать, что 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¶

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

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

STATIC_ROOT¶

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

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

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

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

STATIC_URL¶

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

URL для использования при обращении к статическим файлам, расположенным в STATIC_ROOT.

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

Если не None, то этот путь будет использоваться как базовый для asset definitions (класс Media) и staticfiles app.

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

Вам может понадобиться configure these files to be served in development и обязательно понадобится in production.

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

По умолчанию: 'django.contrib.staticfiles.storage.StaticFilesStorage'

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

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

В качестве примера смотрите Обслуживание статических файлов из облачной службы или CDN.

STATICFILES_FINDERS¶

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

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

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

По умолчанию будут найдены файлы, хранящиеся в настройках 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_TLS
• MANAGERS
• SERVER_EMAIL

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

• DEFAULT_EXCEPTION_REPORTER
• DEFAULT_EXCEPTION_REPORTER_FILTER
• IGNORABLE_404_URLS
• MANAGERS
• SILENCED_SYSTEM_CHECKS

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

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

Формы¶

• FORM_RENDERER
• FORMS_URLFIELD_ASSUME_HTTPS

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

• DATE_FORMAT
• DATE_INPUT_FORMATS
• DATETIME_FORMAT
• DATETIME_INPUT_FORMATS
• DECIMAL_SEPARATOR
• FIRST_DAY_OF_WEEK
• FORMAT_MODULE_PATH
• LANGUAGE_CODE
• LANGUAGE_COOKIE_AGE
• LANGUAGE_COOKIE_DOMAIN
• LANGUAGE_COOKIE_HTTPONLY
• LANGUAGE_COOKIE_NAME
• LANGUAGE_COOKIE_PATH
• LANGUAGE_COOKIE_SAMESITE
• LANGUAGE_COOKIE_SECURE
• LANGUAGES
• LANGUAGES_BIDI
• LOCALE_PATHS
• MONTH_DAY_FORMAT
• NUMBER_GROUPING
• SHORT_DATE_FORMAT
• SHORT_DATETIME_FORMAT
• THOUSAND_SEPARATOR
• TIME_FORMAT
• TIME_INPUT_FORMATS
• TIME_ZONE
• USE_I18N
• USE_THOUSAND_SEPARATOR
• USE_TZ
• YEAR_MONTH_FORMAT

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_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
• X_FRAME_OPTIONS

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

• DEFAULT_CHARSET
• SERIALIZATION_MODULES

Шаблоны¶

• TEMPLATES

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

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

URLs¶

• APPEND_SLASH
• PREPEND_WWW
• ROOT_URLCONF