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 и приложение вызывает исключение, Django отравит e-mail с информацией об исключении. Каждый элемент кортежа должен быть кортежем формата (Полное имя, e-mail). Например:

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

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

ALLOWED_HOSTS¶

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

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

Список может содержать полное имя домена (например 'www.example.com'), тогда значение заголовка Host будет сравниваться с этим значением (проверка без учета регистра и порта). Значение для проверки и поддоменов: '.example.com', удовлетворяет example.com, www.example.com``и всем поддоменам ``example.com. Значение '*' принимает все значения, в этом случае вы сами должны проверять заголовок Host (возможно в middleware, при этом укажите его в MIDDLEWARE_CLASSES).

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 не удовлетворяет ни одному URL-шаблону из URLconf и URL не заканчивается косой чертой, Django верен HTTP перенаправление на этот же URL но с косой чертой в конце. Заметим что такое перенаправление может привести к потере всех данных при POST запросе.

Настройка APPEND_SLASH используется только вместе с CommonMiddleware (смотрите Промежуточный слой (Middleware)). Смотрите PREPEND_WWW.

CACHES¶

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

{
    "default": {
        "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
    }
}

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

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

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

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

CACHE_MIDDLEWARE_ALIAS¶

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

Подключение к кэшу которое используется кэширующим промежуточным слоем.

CACHE_MIDDLEWARE_KEY_PREFIX¶

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

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

Смотрите Система кэширования Django.

CACHE_MIDDLEWARE_SECONDS¶

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

Целое число секунд по умолчанию для кэширования страницы для промежуточного программного обеспечения кэширования <the-per-site-cache>`.

Смотрите Система кэширования Django.

CSRF_COOKIE_AGE¶

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

Время хранения CSRF куки в секундах.

Установка большего времени жизни для CSRF куки может быть необходима, если пользователь закрыл браузер, или добавил страницу в закладки, а потом загрузил страницу из кэша браузера. В без долгоживущей куки отправка форма приведет к ошибке.

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

CSRF_COOKIE_DOMAIN¶

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

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

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

CSRF_COOKIE_HTTPONLY¶

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

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

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

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

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

В описании настройки SESSION_COOKIE_HTTPONLY вы можете найти подробности о HttpOnly.

CSRF_COOKIE_NAME¶

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

Название куки, которая используется для передачи CSRF токена. Может быть каким угодно(но отличаться от названий других кук вашего приложения). Смотрите Подделка межсайтового запроса (CSRF).

CSRF_COOKIE_PATH¶

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

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

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

CSRF_COOKIE_NAME¶

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

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

В описании настройки SESSION_COOKIE_HTTPONLY вы можете найти подробности о HttpOnly.

CSRF_COOKIE_SECURE¶

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

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

CSRF_USE_SESSIONS¶

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

Следует ли хранить токен CSRF в сеансе пользователя, а не в файле cookie. Для этого требуется использование django.contrib.sessions.

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

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

CSRF_FAILURE_VIEW¶

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

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

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

где reason – короткое сообщение (предназначенное для разработчиков или логгирования, не для пользователей) описывающее причину отклонения запроса. Смотрите Подделка межсайтового запроса (CSRF).

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

CSRF_HEADER_NAME¶

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

Название заголовка запроса, который используется при CSRF проверке.

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

CSRF_TRUSTED_ORIGINS¶

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

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

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

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

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

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

DATABASES¶

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

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

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

Самый простой вариант настройки это одна SQLite база данных. Например:

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

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

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

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

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

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

DATA_UPLOAD_MAX_MEMORY_SIZE¶

По умолчанию: 2621440 (то есть 2.5 MB).

Максимальный размер в байтах, который может иметь тело запроса до возникновения SuspiciousOperation (RequestDataTooBig). Проверка выполняется при доступе к request.body или request.POST и рассчитывается на основе общего размера запроса, исключая любые данные загрузки файлов. Вы можете установить значение «Нет», чтобы отключить проверку. Приложениям, которые должны получать сообщения необычно большого размера, следует настроить этот параметр.

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

Смотрите FILE_UPLOAD_MAX_MEMORY_SIZE.

DATA_UPLOAD_MAX_NUMBER_FIELDS¶

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

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

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

DATA_UPLOAD_MAX_NUMBER_FILES¶

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

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

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

DATABASE_ROUTERS¶

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

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

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

DATE_FORMAT¶

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

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

Смотрите 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_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 <strftime-strptime-behavior>`, а не строки формата из фильтра шаблона date. Форматы только даты не включены, поскольку поля даты и времени будут автоматически пытаться использовать DATE_INPUT_FORMATS в крайнем случае.

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

Смотрите DATE_INPUT_FORMATS и TIME_INPUT_FORMATS.

DEBUG¶

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

Включает/выключает режим отладки.

Никогда не включайте DEBUG на «боевом» сервере.

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

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

• 'API'

• 'KEY'

• 'PASS'

• 'SECRET'

• 'SIGNATURE'

• 'TOKEN'

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

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

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

Также при DEBUG равном False, необходимо правильно указать ALLOWED_HOSTS. Иначе все запросы будут возвращать «Bad Request (400)».

DEBUG_PROPAGATE_EXCEPTIONS¶

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

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

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

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-тип не указан явно. Используется вместе с DEFAULT_CONTENT_TYPE при установке заголовка Content-Type.

DEFAULT_EXCEPTION_REPORTER¶

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

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

DEFAULT_EXCEPTION_REPORTER_FILTER¶

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

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

DEFAULT_FROM_EMAIL¶

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

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

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

DEFAULT_INDEX_TABLESPACE¶

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

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

DEFAULT_TABLESPACE¶

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

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

DISALLOWED_USER_AGENTS¶

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

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

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

EMAIL_SSL_CERTFILE не следует использовать с самозаверяющим сертификатом сервера или сертификатом частного центра сертификации (CA). В таких случаях сертификат сервера (или корневой сертификат частного центра сертификации) должен быть установлен в пакет центра сертификации системы. Это можно сделать, следуя инструкциям для конкретной платформы по установке корневого сертификата CA или используя переменные среды OpenSSL SSL_CERT_FILE или SSL_CERT_DIR для указания пользовательского пакета сертификатов (если изменение системного пакета невозможно или желательно).

Для более сложных сценариев SMTP EmailBackend может быть подклассом для добавления корневых сертификатов в его ssl_context с помощью python:ssl.SSLContext.load_verify_locations().

EMAIL_SSL_KEYFILE¶

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

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

Обратите внимание, что установка EMAIL_SSL_CERTFILE и EMAIL_SSL_KEYFILE не приводит к проверке сертификата. Они передаются базовому SSL-соединению. Пожалуйста, обратитесь к документации функции Python 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 MB).

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

Смотрите FILE_UPLOAD_MAX_MEMORY_SIZE

FILE_UPLOAD_DIRECTORY_PERMISSIONS¶

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

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

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

Используется аналогично настройке FILE_UPLOAD_PERMISSIONS.

FILE_UPLOAD_PERMISSIONS¶

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

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

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

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

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

FILE_UPLOAD_TEMP_DIR¶

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

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

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

FIRST_DAY_OF_WEEK¶

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

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

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

FIXTURE_DIRS¶

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

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

Обратите внимание, пути должны быть Unix-стиле, даже для Windows (то есть использовать /).

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

FORCE_SCRIPT_NAME¶

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

Если значение не «Нет», оно будет использоваться как значение переменной среды «SCRIPT_NAME» в любом HTTP-запросе. Этот параметр можно использовать для переопределения предоставленного сервером значения SCRIPT_NAME, которое может быть переписанной версией предпочтительного значения или вообще не предоставляться. Он также используется django.setup() для установки префикса сценария преобразователя URL-адресов вне цикла запрос/ответ (например, в командах управления и автономных сценариях) для генерации правильных URL-адресов, когда указан FORCE_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 путь для импорта Python пакета, который содержит определение форматов для локалей. Если не None, Django попытается найти файл formats.py в каталогах с названием текущей локали и использовать форматы определенные в этом файле.

Предполагается, что имя каталога, содержащего определения формата, будет называться с использованием нотации имя локали, например de, pt_BR, en_US и т. д.

Например, если для параметра 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-ам, для которых не должны отсылаться письма о 404 ошибках (смотрите Как управлять сообщениями об ошибках). Регулярное выражение проверяет полный адрес запроса с учетом всех GET аргументов. Вы можете использовать эту настройку если ваш проект не содержит обычно запрашиваемые файлы, такие как favicon.ico или robots.txt, или если кто-то натравил на ваш сайт скрипт(пер. hammered by script kiddies).

Используется при включенном BrokenLinkEmailsMiddleware (смотрите Промежуточный слой (Middleware)).

INSTALLED_APPS¶

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

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

• классу настройки приложения(рекомендуется), или

• пакету с приложением.

Больше о настройке приложений.

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

INTERNAL_IPS¶

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

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

• Позволяет контекстному процессору debug() добавить некоторые переменные в контекст шаблона.

• Позволяет использовать admindocs bookmarklets, даже без авторизации как пользователь-администратор.

• Помечаются как «внутренние» (вместо «EXTERNAL») в письмах, отправленных через AdminEmailHandler.

LANGUAGE_CODE¶

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

Код используемого в проекте языка. Должен соответствовать формату сокращений названий языков. Например, U.S. English обозначается как "en-us". Смотрите список кодов языков и Интернационализация и локализация.

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

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

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

• Если локализация явно отключена с помощью фильтра unlocalize или тега {% localize off %}, вместо этого будут применяться резервные форматы локализации. Подробности см. в разделе «Управление локализацией в шаблонах <topic-l10n-templates>».

Подробности смотрите в Как Django определяет языковую настройку.

LANGUAGE_COOKIE_AGE¶

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

Время хранения куки локализации в секундах.

LANGUAGE_COOKIE_DOMAIN¶

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

Домен, используемый для кук локализации. Используйте строку, например, ".example.com" (обратите внимание на точку в начале!), для кросдоменних кук, или используйте None для стандартного домена.

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

LANGUAGE_COOKIE_DOMAIN¶

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

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

В описании настройки SESSION_COOKIE_HTTPONLY вы можете найти подробности о HttpOnly.

LANGUAGE_COOKIE_NAME¶

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

Название куки которая используется для хранения текущего языка. Может принимать какое угодно значение (но не должно совпадать с другими куками проекта). Смотрите Интернационализация и локализация.

LANGUAGE_COOKIE_PATH¶

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

Путь(пер. path), который будет использоваться при установке кук локализации. Путь должен соответствовать URL-у вашего проекта или быть родительским относительно него.

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

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

LANGUAGE_COOKIE_NAME¶

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

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

В описании настройки SESSION_COOKIE_HTTPONLY вы можете найти подробности о HttpOnly.

LANGUAGE_COOKIE_AGE¶

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

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

LANGUAGES¶

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

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

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

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

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

from django.utils.translation import gettext_lazy as _

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

LANGUAGES¶

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

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

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

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 ошибки отправляются в email обработчик при DEBUG равном False. Смотрите также Настройка логгирования.

Стандартные настройки логгирования можно найти в файле django/utils/log.py (или посмотреть онлайн).

LOGGING_CONFIG¶

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

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

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

MANAGERS¶

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

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

MEDIA_ROOT¶

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

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

Например: "/var/www/example.com/media/"

Смотрите MEDIA_URL.

MEDIA_URL¶

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

URL который указывает на каталог MEDIA_ROOT, используется для работы с файлами. Должен оканчиваться слешом при не пустом значении. Вам необходимо настроить раздачу этих файлов как dev-сервером, так и «боевым».

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

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

MIDDLEWARE¶

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

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

MIGRATION_MODULES¶

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

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

Например:

{"blog": "blog.db_migrations"}

В этом примере миграции для приложения blog содержатся в пакете blog.db_migrations.

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

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

MONTH_DAY_FORMAT¶

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

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

Например, если отфильтровать страницу списка объектов в интерфейсе администратора по дате, название страницы будет содержать месяц и день. Различные локали содержат различные форматы даты. Например, для U.S. English будет отображаться «January 1,» для Spanish - «1 Enero.»

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

Смотрите доступные форматы. Также смотрите DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT и YEAR_MONTH_FORMAT.

NUMBER_GROUPING¶

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

Количество цифр для группирования в целочисленной части числа.

Используется для разделителя тысяч при отображении чисел. При 0, цифры не будут группироваться. Если значение больше 0, THOUSAND_SEPARATOR будет использоваться как разделитель.

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

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

NUMBER_GROUPING = (3, 2, 0)

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

Смотрите DECIMAL_SEPARATOR, THOUSAND_SEPARATOR и USE_THOUSAND_SEPARATOR.

PREPEND_WWW¶

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

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

ROOT_URLCONF¶

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

Путь для импорта Python-модуля с главной конфигурацией URL-ов. Например: "mydjangoapps.urls". Может быть переопределена для конкретного запроса изменением атрибута urlconf объекта HttpRequest. Подробности смотрите в Как Django обрабатывает запрос.

SECRET_KEY¶

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

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

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

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

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

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

• Всех сессий при использовании любого бэкенда кроме django.contrib.sessions.backends.cache, или при использовании SessionAuthenticationMiddleware с get_session_auth_hash().

• Всех сообщений, если вы используете CookieStorage или FallbackStorage.

• Токены password_reset().

• Для криптографической подписи, если не указан другой ключ.

Когда секретный ключ больше не установлен как 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¶

По умолчанию: 'того же происхождения'

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

SECURE_HSTS_INCLUDE_SUBDOMAINS¶

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

При True SecurityMiddleware добавляет тег includeSubDomains в заголовок HTTP Strict Transport Security. Не имеет эффекта, если не указать в SECURE_HSTS_SECONDS значение отличное от ноля.

SECURE_HSTS_PRELOAD¶

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

При True SecurityMiddleware добавляет тег includeSubDomains в заголовок 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 находится за прокси, который использует не HTTPS соединение к проекту, будут утеряны данные о том, что запрос зашифрованный. В этом случае is_secure() всегда будет возвращать False – даже для запросов, сделанных через HTTPS.

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

SECURE_REDIRECT_EXEMPT¶

По умолчанию: 'того же происхождения'

При True SecurityMiddleware добавит заголовок x-xss-protection для всех ответов, которые еще не содержат его.

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¶

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

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

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

SERVER_EMAIL¶

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

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

SHORT_DATE_FORMAT¶

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

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

Смотрите DATE_FORMAT и SHORT_DATETIME_FORMAT.

SHORT_DATETIME_FORMAT¶

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

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

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

SIGNING_BACKEND¶

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

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

Смотрите Криптографическая подпись.

SILENCED_SYSTEM_CHECKS¶

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

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

Смотрите Система проверки системы.

ХРАНЕНИЯ¶

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

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

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

TEST_RUNNER¶

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

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

TEST_NON_SERIALIZED_APPS¶

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

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

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

THOUSAND_SEPARATOR¶

По умолчанию: ',' (Comma)

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

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

Смотрите NUMBER_GROUPING, DECIMAL_SEPARATOR и USE_THOUSAND_SEPARATOR.

TIME_FORMAT¶

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

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

Смотрите 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.

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

Смотрите DATE_INPUT_FORMATS и DATETIME_INPUT_FORMATS.

TIME_ZONE¶

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

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

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

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

Django устанавливает переменной os.environ['TZ'] значение, указанное в настройке TIME_ZONE. Таким образом все ваши представления и модели будут использовать один и тот же часовой пояс. Однако, 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

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

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

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

USE_X_FORWARDED_HOST¶

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

Указывает, использовать ли заголовок X-Forwarded-Host как более приоритетный чем Host. Включать только при использовании прокси, который устанавливает этот заголовок.

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

USE_X_FORWARDED_PORT¶

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

Булево, которое указывает, использовать ли заголовок X-Forwarded-Port как более приоритетный чем значение SERVER_PORT из META. Включать только при использовании прокси, который устанавливает этот заголовок.

USE_X_FORWARDED_HOST

WSGI_APPLICATION¶

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

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

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

YEAR_MONTH_FORMAT¶

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

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

Например, если отфильтровать страницу списка объектов в интерфейсе администратора по месяцу, название страницы будет содержать год и месяц. Различные локали содержат различные форматы даты. Например, для U.S. English будет отображаться “January 2006”, в то время как для другой локали это может быть - “2006/January”.

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

Смотрите доступные форматы. Также смотрите DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT и MONTH_DAY_FORMAT.

X_FRAME_OPTIONS¶

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

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

AUTHENTICATION_BACKENDS¶

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

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

AUTH_USER_MODEL¶

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

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

LOGIN_REDIRECT_URL¶

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

URL куда перенаправляется пользователь поле авторизации пользователя в представлении contrib.auth.login, если не передан параметр next.

LOGIN_URL¶

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

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

LOGOUT_REDIRECT_URL¶

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

URL куда перенаправляется пользователь поле авторизации пользователя в представлении contrib.auth.login, если не передан параметр next.

Если «Нет», перенаправление выполняться не будет, и будет отображено представление выхода из системы.

PASSWORD_RESET_TIMEOUT¶

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

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

Токены password_reset().

PASSWORD_HASHERS¶

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

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

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

AUTH_PASSWORD_VALIDATORS¶

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

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

MESSAGE_LEVEL¶

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

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

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'

Смотрите бэкенды для хранения сообщейний.

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

MESSAGE_TAGS¶

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

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

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

from django.contrib.messages import constants as message_constants

MESSAGE_TAGS = {message_constants.INFO: ""}

SESSION_CACHE_ALIAS¶

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

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

SESSION_COOKIE_AGE¶

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

Время хранения сесионной куки в секундах.

SESSION_COOKIE_DOMAIN¶

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

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

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

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

Также влияет на работу кук django.contrib.messages.

SESSION_COOKIE_HTTPONLY¶

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

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

HTTPOnly – флаг, добавляемый в HTTP заголовок, который устанавливает куки. Он не является частью стандарта для куки RFC 2109 и поддерживается не всеми браузерами. Однако, если он поддерживается, может помочь ограничить доступ клиентских скриптов к сессионным кукам.

Эта настройка усложнит использование XSS уязвимости для кражи сессии пользователя. Нет важных причин, чтобы не включать эту опцию. Если вы читаете сессионную куку в Javascript, скорее всего вы делаете что-то не так.

SESSION_COOKIE_NAME¶

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

Название для сессионной куки. Может быть каким угодно (но не совпадать с другими куками проекта).

SESSION_COOKIE_PATH¶

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

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

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

SESSION_COOKIE_NAME¶

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

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

Возможные значения параметра:

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

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

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

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

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

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

SESSION_COOKIE_SECURE¶

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

Указывает использовать ли безопасные куки для сессии. Если равна True, куки будут помечены как «безопасные», это означает что браузер будет проверять отослана ли кука через 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'

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

SITE_ID¶

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

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

STATIC_ROOT¶

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

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

Например: "/var/www/example.com/static/"

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

STATIC_URL¶

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

URL, указывающий на каталог со статическими файлами STATIC_ROOT.

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

Если не равен None, будет использовать как базовый путь при определении «media» файлов (класс Media) и приложением staticfiles.

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

Возможно вам понадобится настроить раздачу этих файлов dev-сервером и обязательно сделать это для боевого сервера.

STATICFILES_DIRS¶

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

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

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

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

Заметим, что эти пути должны использовать прямые слэши, то есть быть в Unix-стиле, даже на Windows (например, "C:/Users/user/mysite/extra_static_content").

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

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

STATICFILES_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

Email¶

• 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

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

• FILE_UPLOAD_HANDLERS

• FILE_UPLOAD_MAX_MEMORY_SIZE

• FILE_UPLOAD_PERMISSIONS

• FILE_UPLOAD_TEMP_DIR

• MEDIA_ROOT

• MEDIA_URL

• ХРАНИЛИЩ

Формы¶

• FORM_RENDERER

• FORMS_URLFIELD_ASSUME_HTTPS

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

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_SSL_REDIRECT

  • 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 защита

  • CSRF_COOKIE_DOMAIN

  • CSRF_COOKIE_NAME

  • CSRF_COOKIE_PATH

  • CSRF_COOKIE_NAME

  • CSRF_COOKIE_SECURE

  • CSRF_FAILURE_VIEW

  • CSRF_HEADER_NAME

  • CSRF_TRUSTED_ORIGINS

  • CSRF_TRUSTED_ORIGINS

• 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