Spec-Zone.ru › Django 1.11

Настройки

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

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

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

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

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).

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 rebinding.

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.

См. фреймворк кеширования 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'. Если шаблон с таким именем существует, он будет использован для отрисовки страницы.

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

В template_name был добавлен параметр 403_csrf.html и поведение поиска шаблона с именем csrf_failure().

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. Принимаются те же значения, что и в общем параметре 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'), по которому будет создана тестовая база данных.

CREATE_DB

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

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

Если он установлен в False, тестовые пространства имён таблиц не будут автоматически создаваться в начале тестов или удаляться в конце.

CREATE_USER

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

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

Если он установлен в False, тестовый пользователь не будет автоматически создаваться в начале тестов и удаляться в конце.

USER

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

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

Имя пользователя для подключения к базе данных Oracle, которая будет использоваться при выполнении тестов. Если не указано, Django будет использовать 'test_' + USER.

PASSWORD

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

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

Пароль для подключения к базе данных Oracle, которая будет использоваться при выполнении тестов. Если не указано, Django сгенерирует случайный пароль.

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

В более старых версиях использовался жёстко заданный пароль по умолчанию. Это также было изменено в 1.10.3, 1.9.11 и 1.8.16 для устранения возможных проблем с безопасностью.

TBLSPACE

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

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

Имя пространства имён таблиц, которое будет использоваться при выполнении тестов. Если не указано, Django будет использовать 'test_' + USER.

TBLSPACE_TMP

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

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

Имя временного пространства имён таблиц, которое будет использоваться при выполнении тестов. Если не указано, Django будет использовать 'test_' + USER + '_temp'.

DATAFILE

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

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

Имя файла данных, которое будет использоваться для TBLSPACE. Если не указано, Django будет использовать TBLSPACE + '.dbf'.

DATAFILE_TMP

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

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

Имя файла данных, которое будет использоваться для TBLSPACE_TMP. Если не указано, Django будет использовать TBLSPACE_TMP + '.dbf'.

DATAFILE_MAXSIZE

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

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

Максимальный размер, до которого разрешено увеличиваться DATAFILE.

DATAFILE_TMP_MAXSIZE

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

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

Максимальный размер, до которого разрешено увеличиваться DATAFILE_TMP.

DATA_UPLOAD_MAX_MEMORY_SIZE

Новое в Django 1.10.

Значение по умолчанию: 2621440 (т.е. 2,5 МБ).

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

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

См. также FILE_UPLOAD_MAX_MEMORY_SIZE.

DATA_UPLOAD_MAX_NUMBER_FIELDS

Новое в Django 1.10.

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

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

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

DATABASE_ROUTERS

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

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

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

DATE_FORMAT

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

Формат по умолчанию для отображения полей даты в любой части системы. Обратите внимание, что если USE_L10N установлено в True, то формат, определенный локалью, имеет более высокий приоритет и будет применён вместо него. См. allowed date format strings.

См. также DATETIME_FORMAT, TIME_FORMAT и SHORT_DATE_FORMAT.

DATE_INPUT_FORMATS

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

[
    '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', # '2006-10-25', '10/25/2006', '10/25/06'
    '%b %d %Y', '%b %d, %Y',            # 'Oct 25 2006', 'Oct 25, 2006'
    '%d %b %Y', '%d %b, %Y',            # '25 Oct 2006', '25 Oct, 2006'
    '%B %d %Y', '%B %d, %Y',            # 'October 25 2006', 'October 25, 2006'
    '%d %B %Y', '%d %B, %Y',            # '25 October 2006', '25 October, 2006'
]

Список форматов, которые будут приняты при вводе данных в поле даты. Форматы будут пробоваться в порядке следования, используя первый допустимый формат. Обратите внимание, что эти строки форматирования используют синтаксис модуля Python datetime, а не строки форматирования из фильтра шаблонов date.

Когда USE_L10N равно True, формат, определённый локалью, имеет более высокий приоритет и будет применён вместо него.

См. также DATETIME_INPUT_FORMATS и TIME_INPUT_FORMATS.

DATETIME_FORMAT

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

Формат по умолчанию для отображения полей datetime в любой части системы. Обратите внимание, что если USE_L10N установлено в True, то формат, определённый локалью, имеет более высокий приоритет и будет применён вместо него. См. allowed date format strings.

См. также DATE_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'
    '%Y-%m-%d',              # '2006-10-25'
    '%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',              # '10/25/2006'
    '%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'
    '%m/%d/%y',              # '10/25/06'
]

Список форматов, которые будут приняты при вводе данных в поле datetime. Форматы будут пробоваться в порядке следования, используя первый допустимый формат. Обратите внимание, что эти строки форматирования используют синтаксис модуля Python datetime, а не строки форматирования из фильтра шаблонов date.

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

См. также DATE_INPUT_FORMATS и TIME_INPUT_FORMATS.

DEBUG

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

Булево значение, включающее/отключающее режим отладки.

Никогда не развертывайте сайт в производство с DEBUG включённым.

Вы уловили это? НИКОГДА не развертывайте сайт в производство с DEBUG включённым.

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

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

  • 'API'
  • 'KEY'
  • 'PASS'
  • 'SECRET'
  • 'SIGNATURE'
  • 'TOKEN'

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

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

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

Наконец, если DEBUG имеет значение False, вам также необходимо правильно установить настройку ALLOWED_HOSTS. Если этого не сделать, все запросы будут возвращены как «Плохой запрос (400)».

Примечание

Файл по умолчанию settings.py созданный командой django-admin startproject устанавливает DEBUG = True для удобства.

DEBUG_PROPAGATE_EXCEPTIONS

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

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

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

DECIMAL_SEPARATOR

По умолчанию: '.' (Точка)

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

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

См. также NUMBER_GROUPING, THOUSAND_SEPARATOR и USE_THOUSAND_SEPARATOR.

DEFAULT_CHARSET

По умолчанию: 'utf-8'

Набор символов по умолчанию для всех HttpResponse объектов, если тип MIME не указан вручную. Используется с DEFAULT_CONTENT_TYPE для построения заголовка Content-Type.

DEFAULT_CONTENT_TYPE

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

Тип содержимого по умолчанию для всех HttpResponse объектов, если тип MIME не указан вручную. Используется с DEFAULT_CHARSET для построения заголовка Content-Type.

DEFAULT_EXCEPTION_REPORTER_FILTER

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

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

DEFAULT_FILE_STORAGE

По умолчанию: 'django.core.files.storage.FileSystemStorage'

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

DEFAULT_FROM_EMAIL

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

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

DEFAULT_INDEX_TABLESPACE

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

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

DEFAULT_TABLESPACE

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

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

DISALLOWED_USER_AGENTS

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

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

EMAIL_BACKEND

По умолчанию: 'django.core.mail.backends.smtp.EmailBackend'

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

EMAIL_FILE_PATH

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

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

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

Новое в Django 1.11.

По умолчанию: 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, вы можете указать путь к файлу цепочки сертификатов в формате PEM, который нужно использовать для SSL-соединения.

EMAIL_SSL_KEYFILE

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

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

Обратите внимание, что установка EMAIL_SSL_CERTFILE и EMAIL_SSL_KEYFILE не приводит к проверке сертификатов. Они передаются в базовое SSL-соединение. Обратитесь к документации функции Python ssl.wrap_socket() для получения подробной информации о том, как обрабатываются файл цепочки сертификатов и файл закрытого ключа.

EMAIL_TIMEOUT

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

Устанавливает тайм-аут в секундах для блокирующих операций, таких как попытка подключения.

FILE_CHARSET

По умолчанию: 'utf-8'

Кодировка символов, используемая для декодирования любых файлов, считанных с диска. Это включает файлы шаблонов и исходные файлы SQL-данных.

FILE_UPLOAD_HANDLERS

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

[
    'django.core.files.uploadhandler.MemoryFileUploadHandler',
    'django.core.files.uploadhandler.TemporaryFileUploadHandler',
]

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

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

FILE_UPLOAD_MAX_MEMORY_SIZE

По умолчанию: 2621440 (т. е. 2,5 МБ).

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

См. также DATA_UPLOAD_MAX_MEMORY_SIZE.

FILE_UPLOAD_DIRECTORY_PERMISSIONS

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

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

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

Это значение отражает функциональность и замечания параметра FILE_UPLOAD_PERMISSIONS.

FILE_UPLOAD_PERMISSIONS

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

Числовой режим (т.е. 0o644) для установки режима новых загруженных файлов. Для получения дополнительной информации о значении этих режимов, см. документацию по os.chmod().

Если это значение не задано или равно None, поведение будет зависеть от операционной системы. На большинстве платформ временные файлы будут иметь режим 0o600, а файлы, сохранённые из памяти, будут сохранены с использованием стандартного umask системы.

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

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

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

Всегда добавляйте префикс 0 к режиму.

Если вы не знакомы с режимами файлов, обратите внимание, что ведущий 0 очень важен: он указывает на восьмеричное число, которое является способом указания режимов. Если вы попытаетесь использовать 644, поведение будет совершенно неправильным.

FILE_UPLOAD_TEMP_DIR

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

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

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

FIRST_DAY_OF_WEEK

Значение по умолчанию: 0 (воскресенье)

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

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

FIXTURE_DIRS

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

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

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

См. Предоставление начальных данных с фикстурами и Загрузка фикстур.

FORCE_SCRIPT_NAME

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

Если не None, это будет использоваться в качестве значения переменной среды SCRIPT_NAME в любом запросе HTTP. Это значение можно использовать для переопределения значения, предоставленного сервером SCRIPT_NAME, которое может быть переписанной версией предпочтительного значения или вообще не предоставлено. Также используется в django.setup() для установки префикса скрипта решателя URL вне цикла запроса/ответа (например, в командах управления и автономных скриптах) для генерации правильных URL-адресов, когда SCRIPT_NAME не /.

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

Добавлена поддержка в django.setup().

FORM_RENDERER

Новое в Django 1.11.

Значение по умолчанию: 'django.forms.renderers.DjangoTemplates'

Класс, который рендерит виджеты форм. Он должен реализовывать низкоуровневый API рендеринга.

FORMAT_MODULE_PATH

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

Полный путь к пакету Python, содержащему определения форматов для региональных параметров проекта. Если не None, Django будет проверять наличие файла formats.py, в директории, названной текущим регионом, и будет использовать форматы, определённые в этом файле.

Например, если 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, TIME_FORMAT, DATETIME_FORMAT, YEAR_MONTH_FORMAT, MONTH_DAY_FORMAT, SHORT_DATE_FORMAT, SHORT_DATETIME_FORMAT, FIRST_DAY_OF_WEEK, DECIMAL_SEPARATOR, THOUSAND_SEPARATOR и NUMBER_GROUPING.

IGNORABLE_404_URLS

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

Список скомпилированных объектов регулярных выражений, описывающих URL-адреса, которые следует игнорировать при сообщении об ошибках HTTP 404 по электронной почте (см. Отчёт об ошибках). Регулярные выражения сопоставляются с request's full paths (включая строку запроса, если таковая есть). Используйте это, если ваш сайт не предоставляет часто запрашиваемый файл, такой как favicon.ico или robots.txt, или если он подвергается атакам.

Это используется только в том случае, если BrokenLinkEmailsMiddleware включён (см. Средства промежуточного ПО).

INSTALLED_APPS

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

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

  • классу конфигурации приложения (предпочтительнее), или
  • пакету, содержащему приложение.

Дополнительная информация о конфигурациях приложений.

Используйте реестр приложений для интроспекции

Ваш код никогда не должен напрямую обращаться к INSTALLED_APPS. Используйте django.apps.apps вместо этого.

Имена и метки приложений должны быть уникальными в INSTALLED_APPS

Имя приложения names — полный путь Python к пакету приложения — должно быть уникальным. Нет способа включить одно и то же приложение дважды, кроме дублирования его кода под другим именем.

Метка приложения labels — по умолчанию последняя часть имени — также должна быть уникальной. Например, вы не можете включить как django.contrib.auth , так и myproject.auth. Однако вы можете переименовать приложение с помощью пользовательской конфигурации, которая определяет другое label.

Эти правила применяются независимо от того, ссылается ли INSTALLED_APPS на классы конфигурации приложений или пакеты приложений.

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

INTERNAL_IPS

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

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

  • Разрешить обработчику контекста debug() добавить некоторые переменные в контекст шаблона.
  • Можно использовать закладки админдокументов, даже если вы не вошли в систему как пользователь с правами администратора.
  • Отмечены как «внутренние» (в отличие от «ВНЕШНИЕ») в электронных письмах AdminEmailHandler.

LANGUAGE_CODE

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

Строка, представляющая код языка для этой установки. Она должна соответствовать стандартному формату идентификатора языка. Например, английский язык США — "en-us". Смотрите также список идентификаторов языка и Международная и локальная поддержка.

USE_I18N должен быть активен, чтобы это значение имело какой-либо эффект.

Это служит для двух целей:

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

См. Как Django определяет предпочтительный язык для получения более подробной информации.

LANGUAGE_COOKIE_AGE

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

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

LANGUAGE_COOKIE_DOMAIN

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

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

Будьте осторожны при обновлении этого параметра на сайте в режиме работы. Если вы обновите этот параметр, чтобы включить cookie между доменами на сайте, который ранее использовал стандартную cookie для одного домена, существующие cookie пользователей со старым доменом не будут обновлены. В результате пользователи сайта не смогут изменить язык, пока эти cookie не истекут. Единственный безопасный и надежный способ выполнить переход — это навсегда изменить имя cookie языка (через параметр LANGUAGE_COOKIE_NAME) и добавить промежуточное ПО, которое скопирует значение из старой cookie в новую, а затем удалит старую.

LANGUAGE_COOKIE_NAME

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

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

LANGUAGE_COOKIE_PATH

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

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

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

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

LANGUAGES

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

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

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

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

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

from django.utils.translation import ugettext_lazy as _

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

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

Вы можете увидеть конфигурацию ведения журнала по умолчанию, посмотрев в django/utils/log.py (или просмотрите онлайн-источник).

LOGGING_CONFIG

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

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

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

MANAGERS

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

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

MEDIA_ROOT

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

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

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

См. также MEDIA_URL.

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

MEDIA_ROOT и STATIC_ROOT должны иметь разные значения. До того, как STATIC_ROOT был представлен, было распространено использование или обращение к MEDIA_ROOT для обработки статических файлов; однако, поскольку это может иметь серьёзные последствия для безопасности, есть проверка, чтобы предотвратить это.

MEDIA_URL

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

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

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

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

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

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

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

MEDIA_URL и STATIC_URL должны иметь разные значения. Подробнее см. MEDIA_ROOT.

MIDDLEWARE

Новое в Django 1.10.

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

Список используемых посредников. См. Посредники.

MIDDLEWARE_CLASSES

Устаревшее начиная с версии 1.10: Посредники старого стиля, использующие settings.MIDDLEWARE_CLASSES устарели. Обновите собственные посредники старого стиля и используйте настройку MIDDLEWARE.

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

[
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
]

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

MIGRATION_MODULES

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

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

Пример:

{'blog': 'blog.db_migrations'}

В этом случае миграции, относящиеся к приложению blog будут содержаться в пакете blog.db_migrations.

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

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

MONTH_DAY_FORMAT

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

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

Например, когда страница списка изменений администрирования Django фильтруется по диапазону дат, заголовок для данного дня отображает день и месяц. Разные языковые среды имеют разные форматы. Например, на английском языке США будет "январь 1", в то время как на испанском языке может быть "1 января".

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

См. allowed date format strings. Также см. 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)

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

См. также DECIMAL_SEPARATOR, THOUSAND_SEPARATOR и USE_THOUSAND_SEPARATOR.

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

Добавлена поддержка нестандартной группировки цифр.

PREPEND_WWW

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

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

ROOT_URLCONF

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

Строка, представляющая полный путь импорта URLconf вашего корня. Например: "mydjangoapps.urls". Может быть переопределён на основе каждого запроса путём установки атрибута urlconf на входящий объект HttpRequest. Подробнее см. Обработка запроса Django.

SECRET_KEY

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

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

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

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

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

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

Храните это значение в секрете.

Запуск Django с известным SECRET_KEY обесценивает многие меры безопасности Django и может привести к повышению привилегий и уязвимости удалённого кода.

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

  • Всех сессий, если вы используете любой другой бэкэнд сессий, кроме django.contrib.sessions.backends.cache, или используете по умолчанию get_session_auth_hash().
  • Всех сообщений, если вы используете CookieStorage или FallbackStorage.
  • Всех токенов PasswordResetView.
  • Любое использование криптографического шифрования, если не указан другой ключ.

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

Примечание

Файл по умолчанию settings.py созданный django-admin startproject создаёт уникальный SECRET_KEY для удобства.

SECURE_BROWSER_XSS_FILTER

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

Если True, SecurityMiddleware устанавливает заголовок X-XSS-Protection: 1; mode=block для всех ответов, у которых его нет.

SECURE_CONTENT_TYPE_NOSNIFF

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

Если True, то SecurityMiddleware устанавливает заголовок X-Content-Type-Options: nosniff для всех ответов, у которых его ещё нет.

SECURE_HSTS_INCLUDE_SUBDOMAINS

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

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

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

Неправильная настройка может необратимо (на время действия SECURE_HSTS_SECONDS) сломать ваш сайт. Сначала ознакомьтесь с документацией HTTP Strict Transport Security.

SECURE_HSTS_PRELOAD

Новое в Django 1.11.

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

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

SECURE_HSTS_SECONDS

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

Если установлено ненулевое целое значение, то SecurityMiddleware устанавливает заголовок HTTP Strict Transport Security для всех ответов, у которых его ещё нет.

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

Неправильная настройка может необратимо (на некоторое время) сломать ваш сайт. Сначала ознакомьтесь с документацией HTTP Strict Transport Security.

SECURE_PROXY_SSL_HEADER

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

Кортеж, представляющий комбинацию HTTP-заголовка/значения, указывающего, что запрос защищён. Управляет поведением метода is_secure() объекта запроса.

Это требует некоторого объяснения. По умолчанию, is_secure() может определить, является ли запрос защищённым, проверяя, использует ли запрошенный URL «https://». Это важно для защиты CSRF в Django и может использоваться вашим собственным кодом или приложениями третьих сторон.

Однако, если ваше приложение Django находится за прокси-сервером, прокси-сервер может «поглощать» информацию о том, использует ли исходный запрос HTTPS. Если существует незащищённое соединение между прокси и Django, то is_secure() всегда вернёт False — даже для запросов, выполненных конечным пользователем через HTTPS. Напротив, если между прокси и Django существует защищённое соединение, то is_secure() всегда вернёт True — даже для запросов, первоначально выполненных через HTTP.

В этой ситуации вы захотите настроить свой прокси-сервер на установку пользовательского HTTP-заголовка, который сообщает Django, пришёл ли запрос через HTTPS, и вы захотите установить SECURE_PROXY_SSL_HEADER, чтобы Django знал, какой заголовок искать.

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

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

Здесь мы говорим Django, что доверяем заголовку X-Forwarded-Proto, который приходит от нашего прокси, и каждый раз, когда его значение равно 'https', запрос гарантированно является защищённым (т.е. он первоначально пришёл через HTTPS). Очевидно, вы должны только устанавливать эту настройку, если вы контролируете свой прокси или у вас есть гарантия того, что он правильно устанавливает/удаляет этот заголовок.

Обратите внимание, что заголовок должен быть в формате, используемом request.META — все заглавные буквы и, вероятно, начинающиеся с HTTP_. (Помните, Django автоматически добавляет 'HTTP_' в начало имён x-заголовков перед предоставлением заголовка в request.META.)

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

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

Убедитесь, что ВСЕ из следующего верно, прежде чем устанавливать это (предполагая значения из примера выше):

  • Ваше приложение Django находится за прокси-сервером.
  • Ваш прокси-сервер удаляет заголовок X-Forwarded-Proto из всех входящих запросов. Другими словами, если конечные пользователи включают этот заголовок в свои запросы, прокси-сервер его удалит.
  • Ваш прокси-сервер устанавливает заголовок X-Forwarded-Proto и отправляет его Django, но только для запросов, которые первоначально пришли через HTTPS.

Если что-либо из этого неверно, вы должны оставить эту настройку в None и найти другой способ определить HTTPS, возможно, с помощью пользовательского middleware.

SECURE_REDIRECT_EXEMPT

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

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

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).

Примечание

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

SERIALIZATION_MODULES

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

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

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

SERVER_EMAIL

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

Адрес электронной почты, с которого отправляются сообщения об ошибках, такие как те, которые отправляются ADMINS и MANAGERS.

Почему мои электронные письма отправляются с другого адреса?

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

SHORT_DATE_FORMAT

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

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

См. также DATE_FORMAT и SHORT_DATETIME_FORMAT.

SHORT_DATETIME_FORMAT

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

Доступный формат для отображения полей datetime в шаблонах. Обратите внимание, что если USE_L10N установлено в True, то соответствующий формат, заданный локалью, имеет больший приоритет и будет применён. См. allowed date format strings.

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

SIGNING_BACKEND

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

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

END_OF_DOCUMENT_MARKER

См. также документацию по Криптографическому подписанию.

SILENCED_SYSTEM_CHECKS

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

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

См. также документацию по Системе проверки.

TEMPLATES

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

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

Вот простой пример, который указывает движку шаблонов Django загружать шаблоны из подкаталога templates в каждой установленной приложении:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'APP_DIRS': True,
    },
]

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

BACKEND

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

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

  • 'django.template.backends.django.DjangoTemplates'
  • 'django.template.backends.jinja2.Jinja2'

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

NAME

По умолчанию: см. ниже

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

По умолчанию он равен имени модуля, определяющего класс движка, то есть предпоследней части BACKEND, если не указано иное. Например, если бэкэнд 'mypackage.whatever.Backend', то его имя по умолчанию 'whatever'.

DIRS

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

Директории, в которых движок должен искать файлы шаблонов, в порядке поиска.

APP_DIRS

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

Следует ли движку искать файлы шаблонов внутри установленных приложений.

Примечание

Файл по умолчанию settings.py, созданный django-admin startproject, устанавливает 'APP_DIRS': True.

OPTIONS

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

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

TEST_RUNNER

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

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

TEST_NON_SERIALIZED_APPS

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

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

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

THOUSAND_SEPARATOR

По умолчанию: ',' (Запятая)

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

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

См. также NUMBER_GROUPING, DECIMAL_SEPARATOR и USE_THOUSAND_SEPARATOR.

TIME_FORMAT

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

Формат по умолчанию для отображения временных полей в любой части системы. Обратите внимание, что если USE_L10N установлено в True, то формат, заданный локалью, имеет больший приоритет и будет применён вместо него. См. allowed date format strings.

См. также 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.

Если USE_L10N установлено в True, то формат, заданный локалью, имеет больший приоритет и будет применён вместо него.

См. также DATE_INPUT_FORMATS и DATETIME_INPUT_FORMATS.

TIME_ZONE

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

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

Примечание

С момента первого выпуска Django с TIME_ZONE, установленным в 'America/Chicago', глобальная настройка (используемая, если ничего не определено в файле настроек вашего проекта settings.py) остаётся 'America/Chicago' для обратной совместимости. Шаблоны новых проектов по умолчанию устанавливают 'UTC'.

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

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

В средах Unix (где реализован time.tzset()), Django устанавливает переменную os.environ['TZ'] на часовой пояс, указанный вами в настройке TIME_ZONE. Таким образом, все ваши представления и модели будут автоматически работать в этом часовом поясе. Однако Django не будет устанавливать переменную среды TZ, если вы используете ручную настройку, как описано в ручной настройке параметров. Если Django не установит переменную среды TZ, вам нужно убедиться, что ваши процессы работают в правильной среде.

Примечание

Django не может надёжно использовать альтернативные часовые пояса в среде Windows. Если вы используете Django в Windows, TIME_ZONE должен соответствовать системному часовому поясу.

USE_ETAGS

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

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

Устарело начиная с версии 1.11: Эта настройка устарела в пользу использования ConditionalGetMiddleware, которая устанавливает ETag независимо от этой настройки.

USE_I18N

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

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

См. также LANGUAGE_CODE, USE_L10N и USE_TZ.

Примечание

Файл по умолчанию settings.py, созданный командой django-admin startproject, содержит USE_I18N = True для удобства.

USE_L10N

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

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

См. также LANGUAGE_CODE, USE_I18N и USE_TZ.

Примечание

Файл по умолчанию settings.py , созданный командой django-admin startproject, содержит USE_L10N = True для удобства.

USE_THOUSAND_SEPARATOR

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

Булево значение, указывающее, будет ли отображаться разделитель тысяч в числах. Когда USE_L10N установлено в True, и если это значение также установлено в True, Django будет использовать значения THOUSAND_SEPARATOR и NUMBER_GROUPING для форматирования чисел, если в локали нет собственного разделителя тысяч. Если в формате локали есть разделитель тысяч, он будет иметь больший приоритет и будет использован вместо него.

См. также DECIMAL_SEPARATOR, NUMBER_GROUPING и THOUSAND_SEPARATOR.

USE_TZ

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

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

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

Примечание

Файл по умолчанию settings.py , созданный командой django-admin startproject, содержит USE_TZ = True для удобства.

USE_X_FORWARDED_HOST

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

Булево значение, указывающее, использовать ли заголовок X-Forwarded-Host вместо заголовка Host. Это следует включать только если используется прокси, который устанавливает этот заголовок.

Это значение имеет приоритет над USE_X_FORWARDED_PORT. Согласно RFC 7239#page-7, заголовок 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

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

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

YEAR_MONTH_FORMAT

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

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

Например, когда страница списка изменений Django admin фильтруется по дате, заголовок для заданного месяца отображает месяц и год. Разные локали имеют разные форматы. Например, в США английский формат будет "Январь 2006", в то время как в другой локали это может быть "2006/Январь".

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

См. allowed date format strings. См. также DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT и MONTH_DAY_FORMAT.

X_FRAME_OPTIONS

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

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

Auth

Настройки для django.contrib.auth.

AUTHENTICATION_BACKENDS

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

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

AUTH_USER_MODEL

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

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

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

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

LOGIN_REDIRECT_URL

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

URL, на который перенаправляются запросы после входа в систему, когда представление contrib.auth.login не получает параметр next.

Используется, например, декоратором login_required().

Это значение также принимает имена URL-шаблонов, которые можно использовать для сокращения дублирования конфигурации, так как вам не нужно определять URL в двух местах (settings и URLconf).

LOGIN_URL

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

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

Это значение также принимает имена URL-шаблонов, которые можно использовать для сокращения дублирования конфигурации, так как вам не нужно определять URL в двух местах (settings и URLconf).

LOGOUT_REDIRECT_URL

Новое в Django 1.10.

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

URL, на который перенаправляются запросы после выхода пользователя с использованием LogoutView (если представление не получает аргумент next_page).

Если None, перенаправление не будет выполнено, и представление выхода будет отображено.

Это значение также принимает имена URL-шаблонов, которые можно использовать для сокращения дублирования конфигурации, так как вам не нужно определять URL в двух местах (settings и URLconf).

END_OF_DOCUMENT_MARKER ```

PASSWORD_RESET_TIMEOUT_DAYS

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

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

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.BCryptPasswordHasher',
]
Изменено в Django 1.10:

Из списка по умолчанию были удалены следующие хеширователи:

'django.contrib.auth.hashers.SHA1PasswordHasher'
'django.contrib.auth.hashers.MD5PasswordHasher'
'django.contrib.auth.hashers.UnsaltedSHA1PasswordHasher'
'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher'
'django.contrib.auth.hashers.CryptPasswordHasher'

Рекомендуется использовать обёртку для хеширования паролей для повышения безопасности хешей в вашей базе данных. Если это невозможно, добавьте данную настройку в свой проект и добавьте обратно любые необходимые хеширователи.

Также был добавлен Argon2PasswordHasher.

AUTH_PASSWORD_VALIDATORS

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

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

Сообщения

Настройки для django.contrib.messages.

MESSAGE_LEVEL

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

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

Важно

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

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'

Подробнее см. хранилища сообщений.

Хранилища, использующие cookie - CookieStorage и FallbackStorage - используют значение SESSION_COOKIE_DOMAIN, SESSION_COOKIE_SECURE и SESSION_COOKIE_HTTPONLY при настройке cookie.

MESSAGE_TAGS

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

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

Устанавливает отображение уровня сообщения к тегу сообщения, который обычно отображается как CSS-класс в HTML. Если вы укажете значение, оно будет расширять значения по умолчанию. Это означает, что вам нужно указать только те значения, которые необходимо переопределить. Подробнее см. Отображение сообщений выше.

Важно

Если вы переопределяете MESSAGE_TAGS в файле настроек и полагаетесь на какие-либо встроенные константы, вы должны напрямую импортировать модуль constants , чтобы избежать потенциальных циклических импортов, например:

from django.contrib.messages import constants as message_constants
MESSAGE_TAGS = {message_constants.INFO: ''}

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

Сессии

Настройки для django.contrib.sessions.

SESSION_CACHE_ALIAS

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

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

SESSION_COOKIE_AGE

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

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

SESSION_COOKIE_DOMAIN

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

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

Будьте осторожны при обновлении этой настройки на сайте в производстве. Если вы обновите эту настройку, чтобы включить cookie разных доменов на сайте, который ранее использовал стандартный cookie домена, существующие cookie пользователей будут установлены на старый домен. Это может привести к невозможности входа в систему, пока эти cookie не истекут.

Эта настройка также влияет на cookie, установленные django.contrib.messages.

SESSION_COOKIE_HTTPONLY

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

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

HTTPOnly — это флаг, включённый в заголовок HTTP-ответа Set-Cookie. Это не часть стандарта RFC 2109 для cookie, и он не поддерживается всеми браузерами одинаково. Однако, когда он поддерживается, он может быть полезным способом снизить риск доступа клиентского скрипта к защищённым данным cookie.

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

SESSION_COOKIE_NAME

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

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

SESSION_COOKIE_PATH

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

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

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

SESSION_COOKIE_SECURE

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

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

Так как для перехвата сессии пользователя с помощью пакетного анализатора (например, Firesheep) очень просто, если 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.PickleSerializer'
  • 'django.contrib.sessions.serializers.JSONSerializer'

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

Сайты

Настройки для django.contrib.sites.

SITE_ID

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

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

Статические файлы

Настройки для django.contrib.staticfiles.

STATIC_ROOT

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

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

Пример: "/var/www/example.com/static/"

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

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

Это должен быть пустой целевой каталог для сбора статических файлов из их постоянных расположений в один каталог для удобства развертывания; это не место для постоянного хранения статических файлов. Храните их в каталогах, которые будут найдены средствами поиска staticfiles, finders которые по умолчанию находятся в подкаталогах приложений 'static/' и любых каталогах, которые вы включаете в STATICFILES_DIRS.

STATIC_URL

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

URL для ссылок на статические файлы, расположенные в STATIC_ROOT.

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

Если не None, это будет использоваться в качестве базового пути для определения активов (класс Media и приложения staticfiles.

Должен заканчиваться слешем, если задано ненулевое значение.

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

STATICFILES_DIRS

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

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

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

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

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

Префиксы (необязательно)

Если вы хотите сослаться на файлы в одном из местоположений с дополнительным пространством имён, вы можете необязательно указать префикс в виде кортежей (prefix, path), например:

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

Например, если STATIC_URL установлено на '/static/', команда управления collectstatic соберет файлы «stats» в подкаталоге 'downloads' каталога STATIC_ROOT.

Это позволит вам сослаться на локальный файл '/opt/webfiles/stats/polls_20101022.tar.gz' с помощью '/static/downloads/polls_20101022.tar.gz' в ваших шаблонах, например:

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

STATICFILES_STORAGE

По умолчанию: 'django.contrib.staticfiles.storage.StaticFilesStorage'

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

Готовый экземпляр хранилища, определенного в этой настройке, можно найти в django.contrib.staticfiles.storage.staticfiles_storage.

Пример см. в Обслуживание статических файлов из облачной службы или CDN.

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_FILE_STORAGE.

Примечание

При использовании AppDirectoriesFinder поиска убедитесь, что ваши приложения могут быть найдены staticfiles. Просто добавьте приложение в настройку INSTALLED_APPS вашего сайта.

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

Топический указатель основных настроек

Кэширование

  • CACHES
  • CACHE_MIDDLEWARE_ALIAS
  • CACHE_MIDDLEWARE_KEY_PREFIX
  • CACHE_MIDDLEWARE_SECONDS

База данных

  • DATABASES
  • DATABASE_ROUTERS
  • DEFAULT_INDEX_TABLESPACE
  • DEFAULT_TABLESPACE

Отладка

  • DEBUG
  • DEBUG_PROPAGATE_EXCEPTIONS

Электронная почта

  • 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_FILTER
  • IGNORABLE_404_URLS
  • MANAGERS
  • SILENCED_SYSTEM_CHECKS
END_OF_DOCUMENT_MARKER

Настройки загрузки файлов

  • DEFAULT_FILE_STORAGE
  • FILE_CHARSET
  • FILE_UPLOAD_HANDLERS
  • FILE_UPLOAD_MAX_MEMORY_SIZE
  • FILE_UPLOAD_PERMISSIONS
  • FILE_UPLOAD_TEMP_DIR
  • MEDIA_ROOT
  • MEDIA_URL

Формы

  • FORM_RENDERER

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

  • DATE_FORMAT
  • DATE_INPUT_FORMATS
  • DATETIME_FORMAT
  • DATETIME_INPUT_FORMATS
  • DECIMAL_SEPARATOR
  • FIRST_DAY_OF_WEEK
  • FORMAT_MODULE_PATH
  • LANGUAGE_CODE
  • LANGUAGE_COOKIE_AGE
  • LANGUAGE_COOKIE_DOMAIN
  • LANGUAGE_COOKIE_NAME
  • LANGUAGE_COOKIE_PATH
  • LANGUAGES
  • LOCALE_PATHS
  • MONTH_DAY_FORMAT
  • NUMBER_GROUPING
  • SHORT_DATE_FORMAT
  • SHORT_DATETIME_FORMAT
  • THOUSAND_SEPARATOR
  • TIME_FORMAT
  • TIME_INPUT_FORMATS
  • TIME_ZONE
  • USE_I18N
  • USE_L10N
  • USE_THOUSAND_SEPARATOR
  • USE_TZ
  • YEAR_MONTH_FORMAT

HTTP

  • DATA_UPLOAD_MAX_MEMORY_SIZE
  • DATA_UPLOAD_MAX_NUMBER_FIELDS
  • DEFAULT_CHARSET
  • DEFAULT_CONTENT_TYPE
  • DISALLOWED_USER_AGENTS
  • FORCE_SCRIPT_NAME
  • INTERNAL_IPS
  • MIDDLEWARE
  • MIDDLEWARE_CLASSES
  • Безопасность
    • SECURE_BROWSER_XSS_FILTER
    • SECURE_CONTENT_TYPE_NOSNIFF
    • SECURE_HSTS_INCLUDE_SUBDOMAINS
    • SECURE_HSTS_PRELOAD
    • SECURE_HSTS_SECONDS
    • SECURE_PROXY_SSL_HEADER
    • SECURE_REDIRECT_EXEMPT
    • SECURE_SSL_HOST
    • SECURE_SSL_REDIRECT
  • SIGNING_BACKEND
  • USE_ETAGS
  • USE_X_FORWARDED_HOST
  • USE_X_FORWARDED_PORT
  • WSGI_APPLICATION

Ведение журнала

  • LOGGING
  • LOGGING_CONFIG

Модели

  • ABSOLUTE_URL_OVERRIDES
  • FIXTURE_DIRS
  • INSTALLED_APPS

Безопасность

  • Защита от межсайтовых поддельных запросов
    • CSRF_COOKIE_DOMAIN
    • CSRF_COOKIE_NAME
    • CSRF_COOKIE_PATH
    • CSRF_COOKIE_SECURE
    • CSRF_FAILURE_VIEW
    • CSRF_HEADER_NAME
    • CSRF_TRUSTED_ORIGINS
    • CSRF_USE_SESSIONS
  • SECRET_KEY
  • X_FRAME_OPTIONS

Сериализация

  • DEFAULT_CHARSET
  • SERIALIZATION_MODULES

Шаблоны

  • TEMPLATES

Тестирование

  • База данных: TEST
  • TEST_NON_SERIALIZED_APPS
  • TEST_RUNNER

URL

  • APPEND_SLASH
  • PREPEND_WWW
  • ROOT_URLCONF

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/1.11/ref/settings/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API