Полный список настроек

Основные настройки
Здесь приведен список настроек, доступных в ядре 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).

Changed in Django 3.2:
Добавлен бэкэнд PyMemcacheCache.

Changed in Django 4.0:
Был добавлен бэкенд RedisCache.

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

Changed in Django 4.0:
Значения в старых версиях должны включать только имя хоста (возможно, с ведущей точкой), но не схему или звездочку.

Кроме того, проверка заголовков Origin не выполняется в старых версиях.

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 для неограниченных постоянных соединений.

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

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

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

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

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

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

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

SERIALIZE
Булево значение для управления тем, сериализует ли стандартная программа запуска тестов базу данных в JSON-строку в памяти перед запуском тестов (используется для восстановления состояния базы данных между тестами, если у вас нет транзакций). Вы можете установить значение False, чтобы ускорить время создания тестов, если у вас нет тестовых классов с serialized_rollback=True.

Не рекомендуется, начиная с версии 4.0: Этот параметр устарел, так как он может быть выведен из databases при включенной опции serialized_rollback.

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

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

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

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

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

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

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

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

[
'%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', # '2006-10-25', '10/25/2006', '10/25/06'
'%b %d %Y', '%b %d, %Y', # 'Oct 25 2006', 'Oct 25, 2006'
'%d %b %Y', '%d %b, %Y', # '25 Oct 2006', '25 Oct, 2006'
'%B %d %Y', '%B %d, %Y', # 'October 25 2006', 'October 25, 2006'
'%d %B %Y', '%d %B, %Y', # '25 October 2006', '25 October, 2006'
]
Список форматов, которые будут приняты при вводе данных в поле даты. Форматы будут перебираться по порядку, используя первый допустимый. Обратите внимание, что эти строки формата используют Python datetime module syntax, а не строки формата из фильтра шаблона date.

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

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

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

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

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

См. также 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
По умолчанию: '.' (Точка)

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

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

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

DEFAULT_AUTO_FIELD
New in Django 3.2.
По умолчанию: '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'

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

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

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

Указывает тай