Настройки

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

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

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

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

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

`ABSOLUTE_URL_OVERRIDES`

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

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

ABSOLUTE_URL_OVERRIDES = {
    "blogs.blog": lambda o: "/blogs/%s/" % o.slug,
    "news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
}

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

`ADMINS`

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

Список всех людей, которые получают уведомления об ошибках кода. Когда DEBUG=False и AdminEmailHandler настроены в LOGGING (по умолчанию), Django отправляет этим людям подробности исключений, возникших в цикле запрос/ответ.

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

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

`ALLOWED_HOSTS`

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

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

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

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

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

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

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

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

`APPEND_SLASH`

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

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

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

`CACHES`

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

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

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

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

`BACKEND`

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

Используемый кэш-бекенд. Встроенные кэш-бекенды:

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

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

`KEY_FUNCTION`

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

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

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

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

`KEY_PREFIX`

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

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

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

`LOCATION`

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

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

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

`OPTIONS`

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

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

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

`TIMEOUT`

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

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

`VERSION`

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

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

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

`CACHE_MIDDLEWARE_ALIAS`

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

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

`CACHE_MIDDLEWARE_KEY_PREFIX`

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

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

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

`CACHE_MIDDLEWARE_SECONDS`

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

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

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

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

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

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

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

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

`CSRF_HEADER_NAME`

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

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

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

`CSRF_TRUSTED_ORIGINS`

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

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

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

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

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

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

`DATABASES`

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

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

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

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

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

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

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

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

`ATOMIC_REQUESTS`

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

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

`AUTOCOMMIT`

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

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

`ENGINE`

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

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

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

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

`HOST`

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

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

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

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

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

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

`NAME`

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

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

`CONN_MAX_AGE`

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

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

`CONN_HEALTH_CHECKS`

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

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

`OPTIONS`

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

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

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

`PASSWORD`

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

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

`PORT`

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

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

`TIME_ZONE`

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

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

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

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

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

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

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

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

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

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

`DISABLE_SERVER_SIDE_CURSORS`

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

Установите это значение в True, если вы хотите отключить использование курсоров на стороне сервера с QuerySet.iterator(). Пулы транзакций и курсоры на стороне сервера описывает использование.

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

`USER`

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

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

`TEST`

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

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

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

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

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

`CHARSET`

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

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

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

`COLLATION`

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

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

Поддерживается только для бэкенда mysql (см. документацию MySQL для получения подробных сведений).

`DEPENDENCIES`

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

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

`MIGRATE`

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

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

`MIRROR`

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

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

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

`NAME`

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

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

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

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

`TEMPLATE`

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

Имя шаблона (например, 'template0'), на основе которого создаётся тестовая база данных.