Настройки

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

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

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

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

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

`ABSOLUTE_URL_OVERRIDES`

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

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

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

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

`ADMINS`

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

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

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

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

`ALLOWED_HOSTS`

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

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

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

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

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

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

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

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

`APPEND_SLASH`

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

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

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

`CACHES`

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

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

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

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

`BACKEND`

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

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

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

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

`KEY_FUNCTION`

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

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

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

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

`KEY_PREFIX`

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

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

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

`LOCATION`

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

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

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

`OPTIONS`

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

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

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

`TIMEOUT`

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

Количество секунд, после которого запись кэша считается устаревшей. Если значение этой настройки равно None, записи кэша не будут истекать.

`VERSION`

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

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

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

`CACHE_MIDDLEWARE_ALIAS`

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

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

`CACHE_MIDDLEWARE_KEY_PREFIX`

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

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

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

`CACHE_MIDDLEWARE_SECONDS`

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

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

END_OF_DOCUMENT_MARKER

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

`CSRF_COOKIE_AGE`

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

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

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

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

`CSRF_COOKIE_DOMAIN`

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

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

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

`CSRF_COOKIE_HTTPONLY`

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

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

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

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

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

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

`CSRF_COOKIE_NAME`

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

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

`CSRF_COOKIE_PATH`

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

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

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

`CSRF_COOKIE_SAMESITE`

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

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

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

`CSRF_COOKIE_SECURE`

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

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

`CSRF_USE_SESSIONS`

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

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

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

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

`CSRF_FAILURE_VIEW`

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

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

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

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

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

`CSRF_HEADER_NAME`

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

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

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

`CSRF_TRUSTED_ORIGINS`

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

Список хостов, которые считаются надёжными источниками для небезопасных запросов (например, POST). Для небезопасного запроса secure защита Django от подделок межсайтовых запросов требует, чтобы запрос имел заголовок Referer, соответствующий источнику, указанному в заголовке Host . Это предотвращает, например, запрос POST с subdomain.example.com от успешного выполнения против api.example.com. Если вам нужны междоменные небезопасные запросы через HTTPS, продолжая пример, добавьте "subdomain.example.com" в этот список. Настройка также поддерживает поддомены, поэтому можно добавить, например, ".example.com", чтобы разрешить доступ со всех поддоменов example.com.

`DATABASES`

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

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

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

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

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

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

`NAME`

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

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

`CONN_MAX_AGE`

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

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

`OPTIONS`

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

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

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

`PASSWORD`

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

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

`PORT`

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

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

`TIME_ZONE`

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

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

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

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

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

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

`DISABLE_SERVER_SIDE_CURSORS`

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

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

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

`USER`

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

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

`TEST`

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

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

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

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

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

`CHARSET`

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

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

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

`COLLATION`

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

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

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

`DEPENDENCIES`

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

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

`MIRROR`

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

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

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

`NAME`

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

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

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

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

`SERIALIZE`

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

`TEMPLATE`

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

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