Настройки

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

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

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

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

ABSOLUTE_URL_OVERRIDES теперь работает с моделями, которые не объявляют get_absolute_url().

ADMINS

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

Кортеж, перечисляющий людей, которые получают уведомления об ошибках кода. Когда DEBUG=False и представление вызывает исключение, Django отправит этим людям электронное письмо со всей информацией об исключении. Каждый элемент кортежа должен быть кортежем (Полное имя, адрес электронной почты). Пример:

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

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

ALLOWED_HOSTS

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

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

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

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

ALLOWED_HOSTS = [
    '.example.com',  # Allow domain and subdomains
    '.example.com.',  # Also allow FQDN and subdomains
]

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

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

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

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

В более ранних версиях ALLOWED_HOSTS не проверялся, если DEBUG=True, но теперь он проверяется для предотвращения атаки с перенаправлением DNS.

ALLOWED_INCLUDE_ROOTS

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

Устаревшая с версии 1.8: Эта настройка, наряду с тегом шаблона ssi, устарела и будет удалена в Django 1.10.

Вы также можете установить параметр 'allowed_include_roots' в OPTIONS бэкенда DjangoTemplates.

Кортеж строк, представляющих разрешенные префиксы для тега шаблона {% ssi %}. Это мера безопасности, чтобы авторы шаблонов не могли получить доступ к файлам, к которым у них нет доступа.

Например, если ALLOWED_INCLUDE_ROOTS равно ('/home/html', '/var/www'), тогда {% ssi /home/html/foo.txt %} будет работать, но {% ssi /etc/passwd %} — нет.

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

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

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.

CSRF_COOKIE_HTTPONLY

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

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

Это может помочь предотвратить злонамеренный JavaScript от обхода защиты 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_FAILURE_VIEW

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

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

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

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

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_psycopg2',
        '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_psycopg2'
'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.

USER

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

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

TEST

Все TEST подзаписи раньше были независимыми записями в словаре настроек базы данных, с префиксом TEST_. Для обратной совместимости со старыми версиями Django, вы можете определить обе версии настроек, если они совпадают. Кроме того, TEST_CREATE, TEST_USER_CREATE и TEST_PASSWD были изменены на CREATE_DB, CREATE_USER и PASSWORD соответственно.

По умолчанию: {}

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

END_OF_DOCUMENT_MARKER

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

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

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

КОДИРОВКА

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

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

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

СОРТИРОВКА

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

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

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

ЗАВИСИМОСТИ

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

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

ДУБЛИКАТ

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

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

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

НАЗВАНИЕ

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

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

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

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

СЕРИАЛИЗАЦИЯ

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