Настройки

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

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

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

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, вы обходите эту защиту безопасности.

Изменено в Django 1.11:

В более старых версиях, ALLOWED_HOSTS не проверялось во время выполнения тестов.

В более старых версиях, ALLOWED_HOSTS не проверялось, если DEBUG=True. Это также было изменено в Django 1.10.3, 1.9.11 и 1.8.16 для предотвращения атак DNS ребаиндинга.

`APPEND_SLASH`

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

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

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

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

`CACHE_MIDDLEWARE_KEY_PREFIX`

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

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

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

`CACHE_MIDDLEWARE_SECONDS`

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

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

См. фреймворк кэширования 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_SECURE`

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

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

`CSRF_USE_SESSIONS`

Новое в Django 1.11.

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

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

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

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

`NAME`

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

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

`CONN_MAX_AGE`

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

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

`OPTIONS`

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

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

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

`PASSWORD`

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

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

`PORT`

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

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

`TIME_ZONE`

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

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

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

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

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

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

`DISABLE_SERVER_SIDE_CURSORS`

Новое в Django 1.11.1.

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

Новое в Django 1.11.

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

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