Настройки

• Основные настройки
• Авторизация
• Сообщения
• Сессии
• Сайты
• Статические файлы
• Топический индекс основных настроек

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

Вот список настроек, доступных в ядре Django, и их значения по умолчанию. Настройки, предоставляемые приложениями contrib, перечислены ниже, за которыми следует топический индекс основных настроек. Для вводной информации см. руководство по настройкам.

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

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

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

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

Когда DEBUG равно True и ALLOWED_HOSTS пусто, хост проверяется на соответствие ['.localhost', '127.0.0.1', '[::1]'].

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

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

APPEND_SLASH

Значение по умолчанию: True

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

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

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

См. документацию по кэшированию для получения дополнительной информации.

KEY_PREFIX

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

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

См. документацию по кэшированию для получения дополнительной информации.

LOCATION

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

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

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

OPTIONS

Значение по умолчанию: None

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

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

TIMEOUT

Значение по умолчанию: 300

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

VERSION

Значение по умолчанию: 1

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

См. документацию по кэшированию для получения дополнительной информации.

CACHE_MIDDLEWARE_ALIAS

Значение по умолчанию: 'default'

Подключение к кэшу для использования в middleware кэша.

CACHE_MIDDLEWARE_KEY_PREFIX

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

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

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

CACHE_MIDDLEWARE_SECONDS

Значение по умолчанию: 600

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

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

CSRF_COOKIE_AGE

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

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

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

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

CSRF_COOKIE_DOMAIN

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

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

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

CSRF_COOKIE_HTTPONLY

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

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

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

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

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

См. SESSION_COOKIE_HTTPONLY для получения подробной информации о HttpOnly.

CSRF_COOKIE_NAME

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

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

CSRF_COOKIE_PATH

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

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

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

CSRF_COOKIE_SAMESITE

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

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

См. SESSION_COOKIE_SAMESITE для получения подробной информации о SameSite.

CSRF_COOKIE_SECURE

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

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

CSRF_USE_SESSIONS

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

Хранить токен CSRF в сессии пользователя вместо куки. Требует использования django.contrib.sessions.

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

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

CSRF_FAILURE_VIEW

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

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

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

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

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

CSRF_HEADER_NAME

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

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

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

CSRF_TRUSTED_ORIGINS

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

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

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

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

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

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

DATABASES

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

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

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

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

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

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

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

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

ATOMIC_REQUESTS

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

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

AUTOCOMMIT

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

Установите это значение в False если вы хотите отключить управление транзакциями Django и реализовать собственное.

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 («локальные» строки в pg_hba.conf). Если ваш сокет доменной системы Unix не находится в стандартном месте, используйте то же значение unix_socket_directory из postgresql.conf. Если вы хотите подключиться через сокеты TCP, установите HOST на ‘localhost’ или ‘127.0.0.1’ («строки хоста» в pg_hba.conf). В Windows всегда следует определять HOST, так как сокеты доменной системы Unix недоступны.

NAME

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

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

CONN_MAX_AGE

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

Срок жизни соединения с базой данных в секундах (целое число). Используйте 0 для закрытия соединений с базой данных в конце каждого запроса — историческое поведение Django — и None для неограниченного постоянных соединений с базой данных.

CONN_HEALTH_CHECKS

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

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

OPTIONS

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

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

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

PASSWORD

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

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

PORT

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

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

TIME_ZONE

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

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

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

Когда USE_TZ равно False, установка этого параметра приводит к ошибке.

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

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

  • Если Django управляет базой данных и у вас нет веских причин поступать иначе, оставьте этот параметр без значения. Лучше хранить даты и время в UTC, так как это позволяет избежать неоднозначных или несуществующих дат и времени во время перехода на летнее время. Кроме того, получение дат и времени в UTC упрощает арифметику с датами и временем — нет необходимости учитывать возможные изменения смещения во время перехода на летнее время.
  • Если вы подключаетесь к сторонней базе данных, которая хранит даты и время в местном времени, а не в UTC, вам необходимо установить этот параметр в соответствующий часовой пояс. Точно так же, если Django управляет базой данных, но сторонние системы подключаются к той же базе данных и ожидают найти даты и время в местном времени, вам необходимо установить этот параметр.

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

  Хотя установка параметра TIME_ZONE очень редко необходима, есть ситуации, когда это становится необходимым. В частности, рекомендуется согласовать общий параметр TIME_ZONE при работе с сырыми запросами, включающими функции даты и времени, такие как PostgreSQL date_trunc() или generate_series(), особенно при создании временных рядов, которые переходят на летнее время.

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

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

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

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 для получения подробностей).

DEPENDENCIES

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

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

MIGRATE

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

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

MIRROR

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

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

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

NAME

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

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

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

См. Базу данных для тестирования.

TEMPLATE

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

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

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

См. также FILE_UPLOAD_MAX_MEMORY_SIZE.

DATA_UPLOAD_MAX_NUMBER_FIELDS

Значение по умолчанию: 1000

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

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

DATA_UPLOAD_MAX_NUMBER_FILES

Значение по умолчанию: 100

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

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

DATABASE_ROUTERS

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

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

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

DATE_FORMAT

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

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

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

DATE_INPUT_FORMATS

Значение по умолчанию:

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

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

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

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

DATETIME_FORMAT

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

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

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

DATETIME_INPUT_FORMATS

Значение по умолчанию:

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

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

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

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

DEBUG

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

Логическая переменная, которая включает/выключает режим отладки.

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

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

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

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

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

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

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

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

DEBUG_PROPAGATE_EXCEPTIONS

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

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

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

DECIMAL_SEPARATOR

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

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

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

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

DEFAULT_AUTO_FIELD

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

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

DEFAULT_CHARSET

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

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

DEFAULT_EXCEPTION_REPORTER

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

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

DEFAULT_EXCEPTION_REPORTER_FILTER

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

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

DEFAULT_FILE_STORAGE

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

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

DEFAULT_FROM_EMAIL

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

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

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

DEFAULT_INDEX_TABLESPACE

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

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

DEFAULT_TABLESPACE

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

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

DISALLOWED_USER_AGENTS

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

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

EMAIL_BACKEND

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

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

EMAIL_FILE_PATH

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

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

EMAIL_HOST

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

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

См. также EMAIL_PORT.

EMAIL_HOST_PASSWORD

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

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

См. также EMAIL_HOST_USER.

EMAIL_HOST_USER

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

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

См. также EMAIL_HOST_PASSWORD.

EMAIL_PORT

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

Порт для использования с SMTP-сервером, определённым в EMAIL_HOST.

EMAIL_SUBJECT_PREFIX

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

Префикс темы электронного письма, отправленного с django.core.mail.mail_admins или django.core.mail.mail_managers. Вероятно, вам понадобится добавить конечный пробел.

EMAIL_USE_LOCALTIME

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

Нужно ли отправлять SMTP-заголовок Date электронных писем в часовом поясе системы (True) или в UTC (False).

EMAIL_USE_TLS

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

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

EMAIL_USE_SSL

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

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

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

EMAIL_SSL_CERTFILE

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

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

EMAIL_SSL_KEYFILE

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

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

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

EMAIL_TIMEOUT

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

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

FILE_UPLOAD_HANDLERS

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

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

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

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

FILE_UPLOAD_MAX_MEMORY_SIZE

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

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

См. также DATA_UPLOAD_MAX_MEMORY_SIZE.

FILE_UPLOAD_DIRECTORY_PERMISSIONS

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

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

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

Это значение отражает функциональность и замечания параметра FILE_UPLOAD_PERMISSIONS.

FILE_UPLOAD_PERMISSIONS

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

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

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

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

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

FILE_UPLOAD_TEMP_DIR

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

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

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

FIRST_DAY_OF_WEEK

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

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

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

FIXTURE_DIRS

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

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

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

См. Начальные данные с помощью fixture и Загрузка fixture.

FORCE_SCRIPT_NAME

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

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

FORM_RENDERER

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

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

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

FORMS_URLFIELD_ASSUME_HTTPS

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

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

FORMAT_MODULE_PATH

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

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

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

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

Вы также можете установить этот параметр в список путей Python, например:

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

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

Доступные форматы:

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

IGNORABLE_404_URLS

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

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

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

INSTALLED_APPS

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

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

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

Дополнительная информация о конфигурациях приложений.

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

INTERNAL_IPS

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

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

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

LANGUAGE_CODE

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

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

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

Он выполняет две функции:

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

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

LANGUAGE_COOKIE_AGE

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

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

LANGUAGE_COOKIE_DOMAIN

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

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

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

LANGUAGE_COOKIE_HTTPONLY

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

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

См. SESSION_COOKIE_HTTPONLY для получения дополнительной информации о HttpOnly

LANGUAGE_COOKIE_NAME

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

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

LANGUAGE_COOKIE_PATH

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

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

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

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

LANGUAGE_COOKIE_SAMESITE

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

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

См. SESSION_COOKIE_SAMESITE для получения дополнительной информации о SameSite

LANGUAGE_COOKIE_SECURE

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

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

LANGUAGES

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

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

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

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

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

from django.utils.translation import gettext_lazy as _

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

LANGUAGES_BIDI

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

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

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

LOCALE_PATHS

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

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

Пример:

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

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

LOGGING

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

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

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

Вы можете увидеть конфигурацию журнала по умолчанию, посмотрев в django/utils/log.py.

LOGGING_CONFIG

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

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

Если вы установите LOGGING_CONFIG в None, процесс конфигурации логирования будет пропущен.

MANAGERS

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

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

MEDIA_ROOT

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

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

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

См. также MEDIA_URL.

MEDIA_URL

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

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

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

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

MIDDLEWARE

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

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

MIGRATION_MODULES

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

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

Пример:

{"blog": "blog.db_migrations"}

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

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

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

MONTH_DAY_FORMAT

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

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

Например, когда страница списка изменений Django админки фильтруется по диапазону дат, заголовок для определенного дня отображает день и месяц. Разные языковые локали имеют разные форматы. Например, в английском языке США будет "Январь 1", а в испанском - "1 Января".

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

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

NUMBER_GROUPING

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

Количество цифр, сгруппированных вместе в целой части числа.

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

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

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

NUMBER_GROUPING = (3, 2, 0)

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

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

PREPEND_WWW

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

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

ROOT_URLCONF

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

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

SECRET_KEY

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

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

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

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

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

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

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

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

SECRET_KEY_FALLBACKS

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

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

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

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

SECURE_CONTENT_TYPE_NOSNIFF

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

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

SECURE_CROSS_ORIGIN_OPENER_POLICY

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

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

SECURE_HSTS_INCLUDE_SUBDOMAINS

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

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

SECURE_HSTS_PRELOAD

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

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

SECURE_HSTS_SECONDS

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

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

SECURE_PROXY_SSL_HEADER

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

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

По умолчанию, is_secure() определяет, является ли запрос безопасным, подтверждая, что запрашиваемый URL использует https://. Этот метод важен для защиты 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 перед тем, как сделать заголовок доступным в request.META.)

SECURE_REDIRECT_EXEMPT

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

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

SECURE_REFERRER_POLICY

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

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

SECURE_SSL_HOST

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

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

SECURE_SSL_REDIRECT

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

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

SERIALIZATION_MODULES

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

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

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

SERVER_EMAIL

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

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

SHORT_DATE_FORMAT

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

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

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

SHORT_DATETIME_FORMAT

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

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

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

SIGNING_BACKEND

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

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

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

SILENCED_SYSTEM_CHECKS

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

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

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

STORAGES

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

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

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

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

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

Следующий пример settings.py фрагмент кода определяет пользовательское хранилище файлов под названием example:

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

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

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

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

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

OPTIONS

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

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

TEST_RUNNER

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

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

TEST_NON_SERIALIZED_APPS

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

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

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

THOUSAND_SEPARATOR

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

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

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

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

TIME_FORMAT

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

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

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

TIME_INPUT_FORMATS

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

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

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

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

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

TIME_ZONE

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

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

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

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

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

USE_I18N

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

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

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

USE_THOUSAND_SEPARATOR

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

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

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

USE_TZ

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

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

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

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

USE_X_FORWARDED_HOST

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

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

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

USE_X_FORWARDED_PORT

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

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

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

WSGI_APPLICATION

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

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

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

YEAR_MONTH_FORMAT

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

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

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

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

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

X_FRAME_OPTIONS

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

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

Auth

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

AUTHENTICATION_BACKENDS

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

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

AUTH_USER_MODEL

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

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

LOGIN_REDIRECT_URL

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

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

LOGIN_URL

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

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

LOGOUT_REDIRECT_URL

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

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

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

PASSWORD_RESET_TIMEOUT

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

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

Используется PasswordResetConfirmView.

PASSWORD_HASHERS

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

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

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

AUTH_PASSWORD_VALIDATORS

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

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

Сообщения

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

MESSAGE_LEVEL

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

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

from django.contrib.messages import constants as message_constants

MESSAGE_LEVEL = message_constants.DEBUG

MESSAGE_STORAGE

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

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

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

Дополнительные сведения см. в разделе хранилища сообщений.

Хранилища, использующие cookie – CookieStorage и FallbackStorage – используют значение SESSION_COOKIE_DOMAIN, SESSION_COOKIE_SECURE и SESSION_COOKIE_HTTPONLY при установке cookie.

MESSAGE_TAGS

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

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

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

from django.contrib.messages import constants as message_constants

MESSAGE_TAGS = {message_constants.INFO: ""}

Сессии

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

SESSION_CACHE_ALIAS

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

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

SESSION_COOKIE_AGE

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

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

SESSION_COOKIE_DOMAIN

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

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

Для использования cookie между доменами с CSRF_USE_SESSIONS необходимо включить ведущую точку (например, ".example.com") для соответствия проверке referer middleware CSRF.

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

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

SESSION_COOKIE_HTTPONLY

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

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

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

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

SESSION_COOKIE_NAME

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

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

SESSION_COOKIE_PATH

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

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

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

SESSION_COOKIE_SAMESITE

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

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

Возможные значения для настройки:

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

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

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

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

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

SESSION_COOKIE_SECURE

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

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

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

SESSION_ENGINE

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

Управляет тем, где Django хранит данные сессии. Включенные движки:

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

См. Настройка движка сессий для получения дополнительной информации.

SESSION_EXPIRE_AT_BROWSER_CLOSE

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

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

SESSION_FILE_PATH

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

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

SESSION_SAVE_EVERY_REQUEST

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

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

SESSION_SERIALIZER

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

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

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

См. Сериализация сессии для получения подробностей.

Сайты

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

SITE_ID

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

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

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

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

STATIC_ROOT

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

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

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

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

STATIC_URL

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

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

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

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

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

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

STATICFILES_DIRS

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

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

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

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

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

STATICFILES_FINDERS

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

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

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

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

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

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

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

Кэш

• CACHES
• CACHE_MIDDLEWARE_ALIAS
• CACHE_MIDDLEWARE_KEY_PREFIX
• CACHE_MIDDLEWARE_SECONDS

База данных

• DATABASES
• DATABASE_ROUTERS
• DEFAULT_INDEX_TABLESPACE
• DEFAULT_TABLESPACE

Отладка

• DEBUG
• DEBUG_PROPAGATE_EXCEPTIONS

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

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

Обработка ошибок

• DEFAULT_EXCEPTION_REPORTER
• DEFAULT_EXCEPTION_REPORTER_FILTER
• IGNORABLE_404_URLS
• MANAGERS
• SILENCED_SYSTEM_CHECKS

Настройки загрузки файлов

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

Формы

• FORM_RENDERER
• FORMS_URLFIELD_ASSUME_HTTPS

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

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

HTTP

• DATA_UPLOAD_MAX_MEMORY_SIZE
• DATA_UPLOAD_MAX_NUMBER_FIELDS
• DATA_UPLOAD_MAX_NUMBER_FILES
• DEFAULT_CHARSET
• DISALLOWED_USER_AGENTS
• FORCE_SCRIPT_NAME
• INTERNAL_IPS
• MIDDLEWARE
• Безопасность
  • SECURE_CONTENT_TYPE_NOSNIFF
  • SECURE_CROSS_ORIGIN_OPENER_POLICY
  • SECURE_HSTS_INCLUDE_SUBDOMAINS
  • SECURE_HSTS_PRELOAD
  • SECURE_HSTS_SECONDS
  • SECURE_PROXY_SSL_HEADER
  • SECURE_REDIRECT_EXEMPT
  • SECURE_REFERRER_POLICY
  • SECURE_SSL_HOST
  • SECURE_SSL_REDIRECT
• SIGNING_BACKEND
• USE_X_FORWARDED_HOST
• USE_X_FORWARDED_PORT
• WSGI_APPLICATION

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

• LOGGING
• LOGGING_CONFIG

Модели

• ABSOLUTE_URL_OVERRIDES
• FIXTURE_DIRS
• INSTALLED_APPS

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

• Защита от межсайтовых запросов
  • CSRF_COOKIE_DOMAIN
  • CSRF_COOKIE_NAME
  • CSRF_COOKIE_PATH
  • CSRF_COOKIE_SAMESITE
  • CSRF_COOKIE_SECURE
  • CSRF_FAILURE_VIEW
  • CSRF_HEADER_NAME
  • CSRF_TRUSTED_ORIGINS
  • CSRF_USE_SESSIONS
• SECRET_KEY
• SECRET_KEY_FALLBACKS
• X_FRAME_OPTIONS

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

• DEFAULT_CHARSET
• SERIALIZATION_MODULES

Шаблоны

• TEMPLATES

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

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

URL-адреса

• APPEND_SLASH
• PREPEND_WWW
• ROOT_URLCONF