Настройки

Предупреждение

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

Основные настройки

Здесь приведен список настроек, доступных в ядре Django, и их значения по умолчанию. Настройки, предоставляемые приложениями, перечислены ниже, за ними следует тематический указатель настроек ядра. Для получения вводного материала смотрите settings topic guide.

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

BACKEND

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

Используемый бэкенд кэша. Встроенными бэкендами кэша являются:

  • 'django.core.cache.backends.db.DatabaseCache'
  • 'django.core.cache.backends.dummy.DummyCache'
  • 'django.core.cache.backends.filebased.FileBasedCache'
  • 'django.core.cache.backends.locmem.LocMemCache'
  • 'django.core.cache.backends.memcached.PyMemcacheCache'
  • 'django.core.cache.backends.memcached.PyLibMCCache'
  • 'django.core.cache.backends.redis.RedisCache'

Вы можете использовать кэш-бэкенд, который не поставляется с Django, установив BACKEND в полностью вычисленный путь класса кэш-бэкенда (т.е. mypackage.backends.whatever.WhateverCache).

KEY_FUNCTION

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

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

Вы можете использовать любую ключевую функцию, если она имеет ту же сигнатуру аргумента.

Более подробную информацию см. в cache documentation.

KEY_PREFIX

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

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

Более подробную информацию см. в cache documentation.

LOCATION

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

Расположение используемого кэша. Это может быть каталог для кэша файловой системы, хост и порт для сервера memcache или идентификационное имя для локального кэша памяти. например:

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

OPTIONS

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

Дополнительные параметры для передачи бэкенду кэша. Доступные параметры зависят от бэкенда кэша.

Некоторую информацию о доступных параметрах можно найти в документации cache arguments. Для получения более подробной информации обратитесь к собственной документации вашего модуля бэкенда.

TIMEOUT

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

Количество секунд до того, как запись в кэше будет считаться устаревшей. Если значение этого параметра равно None, срок действия записей кэша не истекает. Значение 0 приводит к немедленному истечению срока действия ключей (фактически «не кэшировать»).

VERSION

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

Номер версии по умолчанию для ключей кэша, генерируемых сервером Django.

Более подробную информацию см. в cache documentation.

CACHE_MIDDLEWARE_ALIAS

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

Соединение кэша, которое будет использоваться для cache middleware.

CACHE_MIDDLEWARE_KEY_PREFIX

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

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

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

CACHE_MIDDLEWARE_SECONDS

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

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

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

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",
    }
}

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

ATOMIC_REQUESTS

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

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

AUTOCOMMIT

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

Установите это значение False, если вы хотите disable Django’s transaction management и реализовать свой собственный.

ENGINE

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

Используемый бэкенд базы данных. Встроенными бэкендами баз данных являются:

  • 'django.db.backends.postgresql'
  • 'django.db.backends.mysql'
  • 'django.db.backends.sqlite3'
  • 'django.db.backends.oracle'

Вы можете использовать бэкенд базы данных, который не поставляется с Django, установив ENGINE в полностью определенный путь (т.е. mypackage.backends.whatever).

HOST

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

Какой хост использовать при подключении к базе данных. Пустая строка означает localhost. Не используется с SQLite.

Если это значение начинается с прямой косой черты ('/') и вы используете MySQL, MySQL подключится через сокет Unix к указанному сокету. Например:

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

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

Если вы используете PostgreSQL, то по умолчанию (пустое HOST) подключение к базе данных осуществляется через доменные сокеты UNIX (строки „local“ в pg_hba.conf). Если ваш сокет домена UNIX находится не в стандартном месте, используйте то же значение unix_socket_directory из postgresql.conf. Если вы хотите подключаться через TCP сокеты, установите HOST в „localhost“ или „127.0.0.1“ (строки „host“ в pg_hba.conf). В Windows всегда следует задавать HOST, так как доменные сокеты UNIX недоступны.

NAME

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

Имя используемой базы данных. Для SQLite это полный путь к файлу базы данных. При указании пути всегда используйте прямые косые черты, даже в Windows (например, C:/homes/user/mysite/sqlite3.db).

CONN_MAX_AGE

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

Время жизни соединения с базой данных, как целое число секунд. Используйте 0 для закрытия соединений с базой данных в конце каждого запроса - историческое поведение Django - и None для неограниченного persistent database connections.

CONN_HEALTH_CHECKS

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

Если установлено значение True, существующие соединения persistent database connections будут проверяться на работоспособность перед повторным использованием в каждом запросе, выполняющем доступ к базе данных. Если проверка работоспособности не прошла, соединение будет восстановлено без отказа запроса, когда соединение больше не может использоваться, но сервер базы данных готов принимать и обслуживать новые соединения (например, после перезапуска сервера базы данных, закрывающего существующие соединения).

OPTIONS

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

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

Некоторую информацию о доступных параметрах можно найти в документации Database Backends. Для получения более подробной информации обратитесь к собственной документации вашего модуля бэкенда.

PASSWORD

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

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

PORT

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

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

TIME_ZONE

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

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

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

  • Если бэкенд базы данных не поддерживает часовые пояса (например, SQLite, MySQL, Oracle), Django читает и записывает даты в местном времени в соответствии с этой опцией, если она установлена, и в UTC, если нет.

    Изменение часового пояса соединения изменяет способ чтения из базы данных и записи в нее временных данных.

    • Если Django управляет базой данных, и у вас нет веских причин поступать иначе, оставьте этот параметр не установленным. Лучше всего хранить время даты в UTC, так как это позволяет избежать двусмысленных или несуществующих дат при переходе на летнее время. Кроме того, получение времени в UTC упрощает арифметику времени - нет необходимости учитывать возможные изменения смещения при переходе на летнее время.
    • Если вы подключаетесь к сторонней базе данных, которая хранит время в местном времени, а не в UTC, то вы должны установить этот параметр в соответствующий часовой пояс. Аналогично, если Django управляет базой данных, но сторонние системы подключаются к той же базе данных и ожидают найти время в местном времени, то вы должны установить этот параметр.
  • Если бэкенд базы данных поддерживает часовые пояса (например, PostgreSQL), опция TIME_ZONE нужна очень редко. Она может быть изменена в любое время; база данных сама позаботится о преобразовании времени дат в нужный часовой пояс.

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

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

    Рассмотрите возможность явного преобразования к местному времени с помощью AT TIME ZONE в необработанных SQL-запросах вместо установки опции TIME_ZONE.

DISABLE_SERVER_SIDE_CURSORS

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

Установите значение True, если вы хотите отключить использование курсоров на стороне сервера с помощью QuerySet.iterator(). Объединение транзакций и курсоры на стороне сервера описывает вариант использования.

Это специфическая для PostgreSQL настройка.

USER

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

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

TEST

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

Словарь настроек для тестовых баз данных; более подробно о создании и использовании тестовых баз данных смотрите Тестовая база данных.

Вот пример с конфигурацией тестовой базы данных:

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

Доступны следующие ключи в словаре TEST:

CHARSET

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

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

Поддерживается бэкендами PostgreSQL (postgresql) и MySQL (mysql).

COLLATION

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

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

Поддерживается только для бэкенда mysql (подробнее см. MySQL manual).

DEPENDENCIES

По умолчанию: ['default'], для всех баз данных, кроме default, которая не имеет зависимостей.

Зависимости порядка создания базы данных. Подробнее см. документацию по controlling the creation order of test databases.

MIGRATE

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

Если установлено значение False, миграции не будут запускаться при создании тестовой базы данных. Это аналогично установке None в качестве значения в MIGRATION_MODULES, но для всех приложений.

MIRROR

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

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

Эта настройка существует для тестирования конфигураций основной/репликативной (в некоторых базах данных называемой ведущей/ведомой) конфигурации нескольких баз данных. Подробнее см. документацию по testing primary/replica configurations.

NAME

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

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

Если для движка базы данных SQLite используется значение по умолчанию (None), то в тестах будет использоваться база данных, хранящаяся в памяти. Для всех остальных движков баз данных тестовая база данных будет использовать имя 'test_' + DATABASE_NAME.

См. Тестовая база данных.

TEMPLATE

Это специфическая для PostgreSQL настройка.

Имя базы данных template (например, 'template0'), из которой будет создана тестовая база данных.

CREATE_DB

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

Это специфическая для Oracle настройка.

Если он установлен в False, тестовые табличные пространства не будут автоматически создаваться в начале тестов или удаляться в конце.

CREATE_USER

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

Это специфическая для Oracle настройка.

Если он установлен в False, тестовый пользователь не будет автоматически создаваться в начале тестов и удаляться в конце.

USER

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

Это специфическая для Oracle настройка.

Имя пользователя для подключения к базе данных Oracle, которая будет использоваться при выполнении тестов. Если оно не указано, Django будет использовать 'test_' + USER.

PASSWORD

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

Это специфическая для Oracle настройка.

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

ORACLE_MANAGED_FILES

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

Это специфическая для Oracle настройка.

Если установлено значение True, будут использоваться табличные пространства Oracle Managed Files (OMF). Значения DATAFILE и DATAFILE_TMP будут игнорироваться.

TBLSPACE

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

Это специфическая для Oracle настройка.

Имя табличного пространства, которое будет использоваться при выполнении тестов. Если не указано, Django будет использовать 'test_' + USER.

TBLSPACE_TMP

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

Это специфическая для Oracle настройка.

Имя временного табличного пространства, которое будет использоваться при выполнении тестов. Если не указано, Django будет использовать 'test_' + USER + '_temp'.

DATAFILE

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

Это специфическая для Oracle настройка.

Имя файла данных, который будет использоваться для TBLSPACE. Если не указано, Django будет использовать TBLSPACE + '.dbf'.

DATAFILE_TMP

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

Это специфическая для Oracle настройка.

Имя файла данных, который будет использоваться для TBLSPACE_TMP. Если не указано, Django будет использовать TBLSPACE_TMP + '.dbf'.

DATAFILE_MAXSIZE

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

Это специфическая для Oracle настройка.

Максимальный размер, до которого разрешено увеличивать DATAFILE.

DATAFILE_TMP_MAXSIZE

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

Это специфическая для Oracle настройка.

Максимальный размер, до которого разрешено увеличивать DATAFILE_TMP.

DATAFILE_SIZE

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

Это специфическая для Oracle настройка.

Начальный размер файла DATAFILE.

DATAFILE_TMP_SIZE

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

Это специфическая для Oracle настройка.

Начальный размер DATAFILE_TMP.

DATAFILE_EXTSIZE

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

Это специфическая для Oracle настройка.

Размер, на который расширяется DATAFILE, когда требуется больше места.

DATAFILE_TMP_EXTSIZE

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

Это специфическая для Oracle настройка.

Сумма, на которую расширяется DATAFILE_TMP, когда требуется больше места.

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

New in Django 3.2.18.

По умолчанию: 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)».

Примечание

Файл по умолчанию settings.py, созданный django-admin startproject, устанавливает DEBUG = True для удобства.

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_AUTO_FIELD будет соблюдаться при создании новых автоматически создаваемых сквозных таблиц для отношений «многие-ко-многим».

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

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

Чтобы решить эту проблему, необходимо добавить в миграции операцию RunSQL для выполнения необходимого шага ALTER TABLE. Вы можете проверить существующее имя таблицы через sqlmigrate, dbshell или с помощью свойства поля remote_field.through._meta.db_table.

Явно определенные сквозные модели уже обрабатываются системой миграции.

Разрешение автоматических миграций для первичного ключа существующих автоматически создаваемых сквозных таблиц may be implemented at a later date.

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'

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

Не рекомендуется, начиная с версии 4.2: Эта настройка устарела. Начиная с версии Django 4.2, механизм хранения файлов по умолчанию может быть настроен с помощью параметра STORAGES под ключом default.

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.

Предупреждение

Всегда префикс режима с 0o .

Если вы не знакомы с режимами файлов, обратите внимание, что префикс 0o очень важен: он указывает на восьмеричное число, именно так должны указываться режимы. Если вы попытаетесь использовать 644, вы получите совершенно неправильное поведение.

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. В состав класса входят следующие рендереры форм:

FORMS_URLFIELD_ASSUME_HTTPS

New in Django 5.0.

Не рекомендуется, начиная с версии 5.0.

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

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

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 напрямую. Вместо этого используйте django.apps.apps.

Имена и метки приложений должны быть уникальными в INSTALLED_APPS

Application names - точечный Python-путь к пакету приложения - должен быть уникальным. Не существует способа включить одно и то же приложение дважды, кроме как продублировав его код под другим именем.

Приложение labels - по умолчанию заключительная часть имени - также должно быть уникальным. Например, вы не можете включить и django.contrib.auth, и myproject.auth. Однако вы можете перемаркировать приложение с помощью пользовательской конфигурации, определяющей другое label.

Эти правила применяются независимо от того, ссылается ли INSTALLED_APPS на классы конфигурации приложения или на пакеты приложений.

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

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_ROOT и STATIC_ROOT должны иметь разные значения. До появления STATIC_ROOT было принято полагаться на MEDIA_ROOT для обслуживания статических файлов; однако, поскольку это может иметь серьезные последствия для безопасности, для предотвращения этого существует проверка валидности.

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/"

Предупреждение

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

Предупреждение

MEDIA_URL и STATIC_URL должны иметь разные значения. См. раздел MEDIA_ROOT для более подробной информации.

Примечание

Если MEDIA_URL является относительным путем, то к нему будет добавлен префикс из предоставленного сервером значения SCRIPT_NAME (или /, если он не задан). Это облегчает обслуживание приложения Django в подпути без добавления дополнительной конфигурации в настройки.

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 не установлен.

Предупреждение

Держите это значение в секрете.

Запуск Django с известным значением SECRET_KEY нарушает многие средства защиты Django и может привести к повышению привилегий и уязвимостям удаленного выполнения кода.

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

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

Примечание

Файл по умолчанию settings.py, созданный django-admin startproject, для удобства создает уникальный SECRET_KEY.

SECRET_KEY_FALLBACKS

D

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

I

Примечание

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

SECURE_HSTS_INCLUDE_SUBDOMAINS

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

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

Предупреждение

Неправильная установка этого параметра может необратимо (для значения SECURE_HSTS_SECONDS) сломать ваш сайт. Сначала прочитайте документацию по Строгая транспортная безопасность HTTP.

SECURE_HSTS_PRELOAD

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

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

SECURE_HSTS_SECONDS

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

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

Предупреждение

Неправильная установка этого параметра может необратимо (на некоторое время) сломать ваш сайт. Сначала прочитайте документацию Строгая транспортная безопасность 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).

Предупреждение

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

Перед установкой этого параметра убедитесь, что ВСЕ следующие параметры истинны (при условии использования значений из примера выше):

  • Ваше приложение Django находится за прокси-сервером.
  • Ваш прокси удаляет заголовок X-Forwarded-Proto из всех входящих запросов, даже если он содержит список протоколов, разделенных запятыми. Другими словами, если конечные пользователи включают этот заголовок в свои запросы, прокси отбрасывает его.
  • Ваш прокси устанавливает заголовок X-Forwarded-Proto и отправляет его в Django, но только для запросов, изначально пришедших по HTTPS.

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

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).

Примечание

Если установка значения True приводит к бесконечным перенаправлениям, это, вероятно, означает, что ваш сайт работает за прокси-сервером и не может определить, какие запросы безопасны, а какие нет. Ваш прокси-сервер, вероятно, устанавливает заголовок для обозначения безопасных запросов; вы можете устранить проблему, выяснив, что это за заголовок, и настроив параметр SECURE_PROXY_SSL_HEADER соответствующим образом.

SERIALIZATION_MODULES

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

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

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

SERVER_EMAIL

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

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

Почему мои электронные письма отправляются с другого адреса?

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

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

New in Django 4.2.

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

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

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

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

Ниже приведен пример 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,
    },
]

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

BACKEND

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

Используемый бэкенд шаблонов. Встроенными бэкендами шаблонов являются:

  • 'django.template.backends.django.DjangoTemplates'
  • 'django.template.backends.jinja2.Jinja2'

Вы можете использовать бэкенд шаблонов, который не поставляется с Django, установив BACKEND в полностью определенный путь (т.е. 'mypackage.whatever.Backend').

NAME

По умолчанию: см. ниже

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

По умолчанию используется имя модуля, определяющего класс движка, т.е. предпоследний кусок BACKEND, если он не указан. Например, если бэкенд - это 'mypackage.whatever.Backend', то его имя по умолчанию будет 'whatever'.

DIRS

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

Каталоги, в которых движок должен искать исходные файлы шаблонов, в порядке поиска.

APP_DIRS

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

Должен ли движок искать исходные файлы шаблонов внутри установленных приложений.

Примечание

По умолчанию файл settings.py, созданный django-admin startproject, устанавливает 'APP_DIRS': True.

OPTIONS

По умолчанию: {} (Пустой дикт)

Дополнительные параметры для передачи бэкенду шаблона. Доступные параметры зависят от бэкенда шаблона. Параметры встроенных бэкендов см. в DjangoTemplates и Jinja2.

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 был впервые выпущен с TIME_ZONE, установленным на 'America/Chicago', глобальная настройка (используемая, если в settings.py вашего проекта ничего не определено) остается 'America/Chicago' для обратной совместимости. Новые шаблоны проектов по умолчанию имеют значение 'UTC'.

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

Примечание

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

USE_I18N

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

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

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

Примечание

Файл по умолчанию settings.py, созданный django-admin startproject, включает USE_I18N = True для удобства.

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.

Changed in Django 5.0:

В старых версиях значение по умолчанию - False.

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.

Авторизация

Настройки для django.contrib.auth.

AUTHENTICATION_BACKENDS

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

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

AUTH_USER_MODEL

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

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

Предупреждение

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

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

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

Сообщения

Настройки для django.contrib.messages.

MESSAGE_LEVEL

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

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

Отказ от циркулярного импорта

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

from django.contrib.messages import constants as message_constants

MESSAGE_LEVEL = message_constants.DEBUG

При желании вы можете задать числовые значения для констант непосредственно в соответствии со значениями в приведенном выше constants table.

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. Если вы укажете значение, оно расширит значение по умолчанию. Это означает, что вы должны указать только те значения, которые вам нужно переопределить. Более подробно смотрите Отображение сообщений выше.

Отказ от циркулярного импорта

Если вы переопределяете MESSAGE_TAGS в вашем файле настроек и полагаетесь на любую из встроенных констант, вы должны импортировать модуль constants напрямую, чтобы избежать возможности циклического импорта, например:

from django.contrib.messages import constants as message_constants

MESSAGE_TAGS = {message_constants.INFO: ""}

При желании вы можете задать числовые значения для констант непосредственно в соответствии со значениями в приведенном выше constants table.

Сессии

Настройки для django.contrib.sessions.

SESSION_CACHE_ALIAS

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

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

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'

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

Сайты

Настройки для django.contrib.sites.

SITE_ID

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

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

Статические файлы

Настройки для django.contrib.staticfiles.

STATIC_ROOT

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

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

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

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

Предупреждение

Это должен быть изначально пустой каталог назначения для сбора ваших статических файлов из их постоянных местоположений в один каталог для удобства развертывания; это не место для постоянного хранения ваших статических файлов. Вы должны сделать это в каталогах, которые будут найдены staticfiles’s finders, которые по умолчанию являются 'static/' app sub-directories и любые каталоги, которые вы включите в STATICFILES_DIRS).

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.

Примечание

Если STATIC_URL является относительным путем, то к нему будет добавлен префикс из предоставленного сервером значения SCRIPT_NAME (или /, если он не задан). Это облегчает обслуживание приложения Django в подпути без добавления дополнительной конфигурации в настройки.

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").

Префиксы (необязательно)

Если вы хотите ссылаться на файлы в одном из мест с дополнительным пространством имен, вы можете опционально указать префикс в виде кортежей (prefix, path), например:

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

Например, если у вас STATIC_URL установлено значение 'static/', команда управления collectstatic соберет файлы «stats» в подкаталоге 'downloads' в каталоге STATIC_ROOT.

Это позволит вам ссылаться на локальный файл '/opt/webfiles/stats/polls_20101022.tar.gz' с '/static/downloads/polls_20101022.tar.gz' в ваших шаблонах, например:

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

STATICFILES_STORAGE

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

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

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

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

Не рекомендуется, начиная с версии 4.2: Эта настройка устарела. Начиная с версии Django 4.2, механизм хранения статических файлов может быть настроен с помощью параметра STORAGES под ключом staticfiles.

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.

Примечание

При использовании поисковика AppDirectoriesFinder убедитесь, что ваши приложения могут быть найдены staticfiles, добавив приложение в настройки INSTALLED_APPS на вашем сайте.

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

Тематический указатель основных параметров

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

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

Шаблоны

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

Вернуться на верх