Настройки

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

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

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

ABSOLUTE_URL_OVERRIDES

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

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

ABSOLUTE_URL_OVERRIDES = {
    'blogs.weblog': 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.MemcachedCache'
• 'django.core.cache.backends.memcached.PyLibMCCache'

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

VERSION

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

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

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

CACHE_MIDDLEWARE_ALIAS

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

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

CACHE_MIDDLEWARE_KEY_PREFIX

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

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

См. фреймворк кэша Django.

CACHE_MIDDLEWARE_SECONDS

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

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

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

CSRF_COOKIE_AGE

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

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

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

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

CSRF_COOKIE_DOMAIN

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

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

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

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). Для secure небезопасного запроса защита Django от подделки межсайтовых запросов требует, чтобы запрос содержал заголовок Referer, который соответствует источнику, представленному в заголовке Host. Это предотвращает, например, запрос POST с subdomain.example.com от успешного выполнения против api.example.com. Если вам необходимы кросс-доменные небезопасные запросы по протоколу HTTPS, продолжив пример, добавьте "subdomain.example.com" в этот список. Настройка также поддерживает поддомены, поэтому вы можете добавить ".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 для неограниченных постоянных соединений.

OPTIONS

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

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

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

PASSWORD

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

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

PORT

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

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

TIME_ZONE

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

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

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

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

Когда USE_TZ равно True и база данных поддерживает часовые пояса (например, PostgreSQL), установка этого параметра является ошибкой.

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

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, у которой нет зависимостей.

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

MIRROR

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

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

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

NAME

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

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

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

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

SERIALIZE

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

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'

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

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

См. также FILE_UPLOAD_MAX_MEMORY_SIZE.

DATA_UPLOAD_MAX_NUMBER_FIELDS

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

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

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

DATABASE_ROUTERS

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

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

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

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

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

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

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

DATETIME_FORMAT

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

Формат по умолчанию для отображения полей datetime в любой части системы. Обратите внимание, что если 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'
    '%Y-%m-%d',              # '2006-10-25'
    '%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',              # '10/25/2006'
    '%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'
    '%m/%d/%y',              # '10/25/06'
]

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

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

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

DEBUG

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

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

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

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

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

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

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

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

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

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

DEBUG_PROPAGATE_EXCEPTIONS

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

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

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

DECIMAL_SEPARATOR

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

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

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

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

DEFAULT_CHARSET

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

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

DEFAULT_EXCEPTION_REPORTER_FILTER

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

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

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 (см. Среднесвязи).

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. Вероятно, вам понадобится включить trailing пробел.

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

EMAIL_TIMEOUT

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

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

FILE_CHARSET

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

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

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

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

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

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

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

FORCE_SCRIPT_NAME

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

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

FORM_RENDERER

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

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

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() добавлять некоторые переменные в контекст шаблона.
• Позволяют использовать закладки admindocs bookmarklets даже если пользователь не залогинен как сотрудник.
• Отмечаются как «внутренние» (в отличие от «EXTERNAL») в электронных письмах AdminEmailHandler.

LANGUAGE_CODE

Значение по умолчанию: 'en-us'

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

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

Это служит двум целям:

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

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

LANGUAGE_COOKIE_AGE

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

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

LANGUAGE_COOKIE_DOMAIN

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

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

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

LANGUAGE_COOKIE_HTTPONLY

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

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

См. SESSION_COOKIE_HTTPONLY для получения подробностей о HttpOnly.

LANGUAGE_COOKIE_NAME

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

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

LANGUAGE_COOKIE_PATH

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

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

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

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

LANGUAGE_COOKIE_SAMESITE

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

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

См. SESSION_COOKIE_SAMESITE для получения подробностей о SameSite.

LANGUAGE_COOKIE_SECURE

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

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

LANGUAGES

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

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

MONTH_DAY_FORMAT

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

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

Например, когда страница изменения списка Django admin фильтруется по дате, заголовок для заданного дня отображает день и месяц. Разные языковые локали имеют разные форматы. Например, в английском США это будет «1 января», а в испанском — «1 Enero».

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

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

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

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

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

SECURE_BROWSER_XSS_FILTER

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

Если True, SecurityMiddleware устанавливает заголовок X-XSS-Protection: 1; mode=block для всех ответов, у которых его ещё нет.

Современные браузеры больше не поддерживают заголовок X-XSS-Protection HTTP. Хотя настройка имеет небольшую практическую пользу, вы всё равно можете установить заголовок, если поддерживаете старые браузеры.

SECURE_CONTENT_TYPE_NOSNIFF

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

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

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

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

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

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

При настройке 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.

SHORT_DATE_FORMAT

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

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

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

SHORT_DATETIME_FORMAT

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

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

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

SIGNING_BACKEND

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

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

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

SILENCED_SYSTEM_CHECKS

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

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

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

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.

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

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

TIME_FORMAT

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

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

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

TIME_INPUT_FORMATS

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

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

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

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

См. также 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_L10N и USE_TZ.

USE_L10N

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

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

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

USE_THOUSAND_SEPARATOR

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

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

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

USE_TZ

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

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

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

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 admin, когда отображаются только год и месяц.

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

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

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

X_FRAME_OPTIONS

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

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

Auth

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

AUTHENTICATION_BACKENDS

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

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

AUTH_USER_MODEL

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

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

LOGIN_REDIRECT_URL

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

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

LOGIN_URL

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

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

LOGOUT_REDIRECT_URL

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

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

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

PASSWORD_RESET_TIMEOUT_DAYS

По умолчанию: 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',
]

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

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

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

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

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

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

• None: отключает флаг.

SESSION_COOKIE_SECURE

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

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

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

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.PickleSerializer'
• 'django.contrib.sessions.serializers.JSONSerializer'

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

Сайты

Настройки для 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.

Готовый экземпляр хранилища, определённого в этой настройке, можно найти в django.contrib.staticfiles.storage.staticfiles_storage.

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

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

Индекс основных настроек

Кэш

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

Формы

• FORM_RENDERER

Глобализация (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_L10N
• USE_THOUSAND_SEPARATOR
• USE_TZ
• YEAR_MONTH_FORMAT

HTTP

• DATA_UPLOAD_MAX_MEMORY_SIZE
• DATA_UPLOAD_MAX_NUMBER_FIELDS
• DEFAULT_CHARSET
• DISALLOWED_USER_AGENTS
• FORCE_SCRIPT_NAME
• INTERNAL_IPS
• MIDDLEWARE
• Безопасность
  • SECURE_BROWSER_XSS_FILTER
  • SECURE_CONTENT_TYPE_NOSNIFF
  • 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
• X_FRAME_OPTIONS

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

• DEFAULT_CHARSET
• SERIALIZATION_MODULES

Шаблоны

• TEMPLATES

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

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

URL

• APPEND_SLASH
• PREPEND_WWW
• ROOT_URLCONF