Примечания к выпуску Django 1.4 ¶

Поддержка часовых поясов ¶

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

В Django 1.4 теперь вы можете переключить Django в более правильный режим с учетом часовых поясов. В этом режиме Django хранит информацию о дате и времени в формате UTC в базе данных, использует внутренние объекты datetime с учетом часового пояса и переводит их в часовой пояс конечного пользователя в шаблонах и формах. Причины использования этой функции:

• Настройка отображения даты и времени для пользователей по всему миру.
• Сохранение даты и времени в формате UTC для переносимости и взаимодействия базы данных. (Этот аргумент неприменим к PostgreSQL, потому что он уже хранит временные метки с информацией о часовом поясе в Django 1.3.)
• Предотвращение проблем с повреждением данных при переходе на летнее время.

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

Поддержка фреймворков для тестирования в браузере ¶

Django 1.4 поддерживает интеграцию с фреймворками для тестирования в браузере, такими как Selenium . Новый django.test.LiveServerTestCaseбазовый класс позволяет более полно тестировать взаимодействие между внешним и внутренним интерфейсом вашего сайта. См. documentationБолее подробную информацию и конкретные примеры.

Обновлен макет проекта по умолчанию и manage.py¶

Django 1.4 поставляется с обновленным макетом проекта по умолчанию и manage.pyфайлом для команды startprojectуправления. Это устраняет некоторые проблемы с предыдущей manage.pyобработкой путей импорта Python, которые вызывали двойной импорт, проблемы при переходе от разработки к развертыванию и другие проблемы с путями, которые трудно отлаживать.

Предыдущие manage.pyвызываемые функции, которые теперь устарели, и, следовательно, проекты, обновляющиеся до Django 1.4, должны обновить свои manage.py. (Старый стиль manage.pyбудет продолжать работать, как и раньше, до Django 1.6. В 1.5 он будет повышаться DeprecationWarning).

Новый рекомендуемый manage.pyфайл должен выглядеть так:

#!/usr/bin/env python
import os, sys

if __name__ == "__main__":
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")

    from django.core.management import execute_from_command_line

    execute_from_command_line(sys.argv)

{{ project_name }} следует заменить на имя пакета Python фактического проекта.

Если настройки, URLconfs и приложения в проекте импортируются или на них ссылаются с использованием префикса имени проекта (например myproject.settings, и т. Д.), Новый необходимо переместить на один каталог вверх, чтобы он находился за пределами пакета проекта, а не рядом с и .ROOT_URLCONF = "myproject.urls"manage.pysettings.pyurls.py

Например, со следующей компоновкой:

manage.py
mysite/
    __init__.py
    settings.py
    urls.py
    myapp/
        __init__.py
        models.py

Вы можете импортировать mysite.settings, mysite.urlsи mysite.myapp, но не settings, urlsили в myappкачестве топ-уровня модулей.

Все, что импортировано как модуль верхнего уровня, можно разместить рядом с новым manage.py. Например, чтобы отделить «myapp» от модуля проекта и импортировать его просто myapp, поместите его вне mysite/каталога:

manage.py
myapp/
    __init__.py
    models.py
mysite/
    __init__.py
    settings.py
    urls.py

Если один и тот же код импортируется непоследовательно (где-то с префиксом проекта, где-то без него), импорт необходимо будет очистить при переходе на новый manage.py.

Пользовательские шаблоны проектов и приложений ¶

startappИ startprojectкоманда управления теперь имеет --templateопцию для указания пути или URL для пользовательского приложения или шаблона проекта.

Например, Django будет использовать /path/to/my_project_templateкаталог, когда вы запустите следующую команду:

django-admin.py startproject --template=/path/to/my_project_template myproject

Теперь вы также можете указать целевой каталог в качестве второго аргумента для обоих startappи startproject:

django-admin.py startapp myapp /path/to/new/app
django-admin.py startproject myproject /path/to/new/project

Для получения дополнительной информации см startappи startproject документации.

Улучшенная поддержка WSGI ¶

Команда startprojectуправления теперь добавляет wsgi.py модуль в исходный макет проекта, содержащий простое приложение WSGI, которое можно использовать для развертывания с серверами приложений WSGI .

Теперь поддерживает с использованием внешне определенной WSGI Callable, что делает возможным запуск с такой же конфигурацией WSGI , который используется для развертывания. Новый параметр позволяет вам настроить, какой объект WSGI использует.built-in development serverrunserverWSGI_APPLICATIONrunserver

(Команда runfcgiуправления также внутренне обертывает вызываемый объект WSGI, настроенный через WSGI_APPLICATION.)

SELECT FOR UPDATEподдержка ¶

Django 1.4 включает QuerySet.select_for_update()метод, который генерирует SQL-запрос. Это заблокирует строки до конца транзакции, то есть другие транзакции не смогут изменять или удалять строки, соответствующие запросу.SELECT ... FOR UPDATEFOR UPDATE

Для получения дополнительных сведений см. Документацию для select_for_update().

Model.objects.bulk_createв ORM ¶

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

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

Дополнительную bulk_create()информацию см. В документации.

QuerySet.prefetch_related¶

Подобно, select_related()но с другой стратегией и более широким охватом, prefetch_related()был добавлен QuerySet. Этот метод возвращает новое значение, QuerySetкоторое будет выполнять предварительную выборку каждого из указанных связанных запросов в одном пакете, как только запрос начнет оцениваться. В отличие от этого select_related, он выполняет соединения в Python, а не в базе данных, и поддерживает отношения «многие ко многим» GenericForeignKeyи многое другое. Это позволяет исправить очень распространенную проблему производительности, при которой ваш код выполняет O (n) запросов к базе данных (или хуже), если у QuerySet каждого объекта на вашем первичном сервере есть много связанных объектов, которые вам также необходимо получить.

Улучшено хеширование паролей ¶

Система аутентификации Django ( django.contrib.auth) хранит пароли с использованием одностороннего алгоритма. Django 1.3 использует алгоритм SHA1 , но увеличение скорости процессора и теоретические атаки показали, что SHA1 не так безопасен, как хотелось бы. Таким образом, Django 1.4 представляет новую систему хранения паролей: по умолчанию Django теперь использует алгоритм PBKDF2 (как рекомендовано NIST ). Вы также можете легко выбрать другой алгоритм (включая популярный алгоритм bcrypt ). Дополнительные сведения см. В разделе Как Django хранит пароли .

Тип документа HTML5 ¶

Мы переключили админку и другие связанные шаблоны на использование типа документа HTML5. Хотя Django будет осторожно поддерживать совместимость со старыми браузерами, это изменение означает, что вы можете использовать любые функции HTML5, которые вам нужны на страницах администратора, без потери валидности HTML или переопределения предоставленных шаблонов для изменения типа документа.

Список фильтров в интерфейсе администратора ¶

До Django 1.4 adminприложение позволяло указывать фильтры списка изменений, задавая поиск по полю, но не позволяло создавать собственные фильтры. Это было исправлено с помощью простого API (ранее использовавшегося внутри компании и известного как «FilterSpec»). Для получения дополнительных сведений см. Документацию для list_filter.

Множественная сортировка в админке ¶

Список изменений администратора теперь поддерживает сортировку по нескольким столбцам. Он учитывает все элементы orderingатрибута, а сортировка по нескольким столбцам путем нажатия на заголовки предназначена для имитации поведения графических интерфейсов рабочего стола. Мы также добавили get_ordering()метод динамического определения порядка (т. Е. В зависимости от запроса).

Новые ModelAdminметоды ¶

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

Два других новых ModelAdminметода get_list_display()и get_list_display_links() возможность динамической настройки полей и ссылок, отображаемых в списке изменений администратора.

Администратор инлайн уважает права пользователей ¶

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

Инструменты для криптографической подписи ¶

Django 1.4 добавляет как низкоуровневый API для подписи значений, так и высокоуровневый API для установки и чтения подписанных файлов cookie, что является одним из наиболее распространенных способов использования подписи в веб-приложениях.

Дополнительную информацию см. В документации по криптографической подписи .

Серверная часть сеанса на основе файлов cookie ¶

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

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

Мастер создания новой формы ¶

Предыдущий FormWizardfrom django.contrib.formtoolsбыл заменен новой реализацией, основанной на представлениях на основе классов, представленных в Django 1.3. Он имеет подключаемый API хранилища и не требует от мастера обхода скрытых полей на каждом предыдущем шаге.

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

reverse_lazy¶

Была reverse()добавлена версия с отложенной оценкой, позволяющая использовать реверсирование URL-адресов до загрузки URLconf проекта.

Перевод шаблонов URL ¶

Django теперь может искать языковой префикс в шаблоне URL при использовании новой i18n_patterns()вспомогательной функции. Также теперь можно определять переводимые шаблоны URL-адресов с помощью django.utils.translation.ugettext_lazy(). См. Раздел Интернационализация: в шаблонах URL-адресов для получения дополнительной информации о языковом префиксе и способах интернационализации шаблонов URL-адресов.

Поддержка контекстного перевода для и ¶{% trans %}{% blocktrans %}

Поддержка контекстного перевода, представленная в Django 1.3 с помощью pgettextфункции, была расширена на теги шаблонов transи blocktransс помощью context ключевого слова new .

Настраиваемый SingleObjectMixinURLConf kwargs ¶

Два новых атрибута, pk_url_kwarg и slug_url_kwarg, были добавлены для SingleObjectMixinобеспечения возможности настройки аргументов ключевого слова URLconf, используемых для общих представлений одного объекта.

Теги шаблона присвоения ¶

Была assignment_tagдобавлена новая вспомогательная функция, чтобы template.Libraryупростить создание тегов шаблона, которые хранят данные в указанной переменной контекста.

*argsи **kwargsподдержка вспомогательных функций тегов шаблона ¶

Simple_tag , inclusion_tag и вновь введенные assignment_tagшаблон вспомогательные функции теперь могут принимать любое количество позиционных или именованных аргументов. Например:

@register.simple_tag
def my_tag(a, b, *args, **kwargs):
    warning = kwargs['warning']
    profile = kwargs['profile']
    ...
    return ...

Затем в шаблоне тегу шаблона может быть передано любое количество аргументов. Например:

{% my_tag 123 "abcd" book.title warning=message|lower profile=user.profile %}

Нет оборачивания исключений в TEMPLATE_DEBUGрежиме ¶

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

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

truncatecharsшаблонный фильтр ¶

Этот новый фильтр усекает строку, чтобы она не превышала указанное количество символов. Усеченные строки заканчиваются переводимой последовательностью многоточия («…»). См. Документацию для truncatecharsполучения более подробной информации.

staticтег шаблона ¶

В staticfilesприложении contrib появился новый staticтег шаблона для ссылки на файлы, сохраненные в STATICFILES_STORAGEбэкэнде хранилища. Он использует метод серверной части хранилища urlи, следовательно, поддерживает расширенные функции, такие как обслуживание файлов из облачной службы .

CachedStaticFilesStorageсерверная часть хранилища ¶

У staticfilesприложения contrib теперь есть django.contrib.staticfiles.storage.CachedStaticFilesStorageбэкэнд, который кэширует файлы, которые оно сохраняет (при запуске команды collectstatic управления), добавляя хеш MD5 содержимого файла к имени файла. Например, файл css/styles.cssтакже будет сохранен как css/styles.55e7cbb9ba48.css

Простая защита от кликджекинга ¶

Мы добавили промежуточное ПО, чтобы обеспечить простую защиту от кликджекинга с помощью X-Frame-Options заголовка. Он не включен по умолчанию из соображений обратной совместимости, но вы почти наверняка захотите включить его, чтобы закрыть эту дыру в безопасности для браузеров, поддерживающих заголовок.

Улучшения CSRF ¶

Мы внесли различные улучшения в наши функции CSRF, включая ensure_csrf_cookie()декоратор, который может помочь с сайтами с большим количеством AJAX; защита от запросов PUT и DELETE; а CSRF_COOKIE_SECUREи CSRF_COOKIE_PATHнастройки, которые могут улучшить безопасность и полезность защиты CSRF. Дополнительную информацию см. В документации CSRF .

Фильтрация отчетов об ошибках ¶

Мы добавили два декоратора функций sensitive_variables()и sensitive_post_parameters(), чтобы можно было назначать локальные переменные и параметры POST, которые могут содержать конфиденциальную информацию и должны быть отфильтрованы из отчетов об ошибках.

Все параметры POST теперь систематически отфильтровываются из отчетов об ошибках для определенных видов ( login, password_reset_confirm, password_changeи add_viewв django.contrib.auth.views, а также user_change_passwordв приложении администратора) , чтобы предотвратить утечку конфиденциальной информации , такой как пароли пользователей.

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

Расширенная поддержка IPv6 ¶

Django 1.4 теперь может лучше обрабатывать IPv6-адреса с новым GenericIPAddressFieldполем модели, полем GenericIPAddressFieldформы и валидаторами validate_ipv46_addressи validate_ipv6_address.

HTML сравнения в тестах ¶

У базовых классов django.testтеперь есть несколько помощников для сравнения HTML, не спотыкаясь о несущественных различиях в пробелах, цитировании / упорядочивании аргументов и закрытии самозакрывающихся тегов. Вы можете либо сравнить HTML напрямую с новыми утверждениями assertHTMLEqual()и assertHTMLNotEqual()утверждениями, либо использовать html=Trueфлаг с assertContains()и, assertNotContains()чтобы проверить, содержит ли ответ клиента данный фрагмент HTML. Дополнительную информацию см. В документации по утверждениям .

Две новые строки формата даты ¶

dateБыли добавлены два новых формата для использования в фильтрах шаблонов, тегах шаблонов и локализации формата :

• e - имя часового пояса данного объекта datetime
• o - номер года ISO 8601

Пожалуйста , не забудьте обновить ваши пользовательские файлы формата , если они содержат либо eили oв строке формата. Например, в испанском формате локализации ранее использовался только экранированный dсимвол формата:

DATE_FORMAT = r'j \de F \de Y'

Но теперь ему также нужно убежать eи o:

DATE_FORMAT = r'j \d\e F \d\e Y'

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

Незначительные особенности ¶

Django 1.4 также включает несколько небольших улучшений, на которые стоит обратить внимание:

• Более удобная трассировка стека на технической странице 500. Фреймы в трассировке стека, которые ссылаются на код фреймворка Django, затемнены, а фреймы в коде приложения слегка выделены. Это изменение упрощает сканирование трассировки стека на предмет проблем в коде приложения.
• Поддержка табличных пространств в PostgreSQL.
• Настраиваемые имена для simple_tag().
• В документации полезная страница обзора безопасности .
• django.contrib.auth.models.check_passwordФункция была перенесена в django.contrib.auth.hashersмодуль. Импорт из старого местоположения по-прежнему будет работать, но вам следует обновить импорт.
• У collectstaticкоманды управления теперь есть --clearвозможность удалить все файлы в месте назначения перед копированием или связыванием статических файлов.
• Теперь можно загружать фикстуры, содержащие прямые ссылки, при использовании MySQL с движком базы данных InnoDB.
• Новый обработчик ответа 403 был добавлен как 'django.views.defaults.permission_denied'. Вы можете установить свой собственный обработчик, установив значение django.conf.urls.handler403. Дополнительную информацию см. В документации о представлении 403 (HTTP запрещено) .
• Команда makemessagesиспользует новый и более точный лексер JsLex для извлечения переводимых строк из файлов JavaScript.

• transШаблонный тег теперь принимает необязательный asаргумент , чтобы иметь возможность получить строку перевода без его отображения , но установка переменного контекста шаблона вместо.

• ifШаблонный тег теперь поддерживает положения.{% elif %}

• Если ваше приложение Django находится за прокси-сервером, вы можете найти новую SECURE_PROXY_SSL_HEADERнастройку полезной. Это решает проблему того, что ваш прокси-сервер «съедает» тот факт, что запрос пришел через HTTPS. Но используйте этот параметр, только если знаете, что делаете.

• Новая, обычный текст, версия коды состояния внутренней страницы ошибок HTTP 500 подается , когда DEBUGбудет Trueтеперь отправляется клиенту , когда Джанго обнаруживает , что запрос возник в коде JavaScript. ( is_ajax()для этого используется.)

  Как и его HTML-аналог, он содержит набор различной информации о состоянии приложения.

  Это должно упростить чтение при отладке взаимодействия с клиентским JavaScript.

• Добавлена опция.makemessages --no-location

• Изменен locmemбэкэнд кеширования pickle.HIGHEST_PROTOCOLдля лучшей совместимости с другими бэкэндами кеша.

• Добавлена ​​поддержка в ORM для генерации SELECTзапросов, содержащих файлы .DISTINCT ON

  Теперь distinct() QuerySetметод принимает необязательный список имен полей модели. Если указано, то DISTINCTоператор ограничивается этими полями. Это поддерживается только в PostgreSQL.

  Для получения дополнительных сведений см. Документацию для distinct().

• На странице входа администратора будет добавлена ​​ссылка для сброса пароля, если вы 'admin_password_reset'включите URL-адрес с именем в свой urls.py, поэтому подключить встроенный механизм сброса пароля и сделать его доступным теперь намного проще. Подробнее см. Добавление функции сброса пароля .

• Серверная часть базы данных MySQL теперь может использовать функцию точки сохранения, реализованную в MySQL версии 5.0.3 или новее с механизмом хранения InnoDB.

• Теперь можно передавать начальные значения в формы модели, которые являются частью как наборов форм модели, так и наборов форм встроенных моделей, возвращаемых из фабричных функций modelformset_factoryи, inlineformset_factoryсоответственно, точно так же, как с обычными наборами форм. Однако начальные значения применяются только к дополнительным формам, то есть к тем, которые не привязаны к существующему экземпляру модели.

• Платформа карты сайта теперь может обрабатывать ссылки HTTPS с помощью нового Sitemap.protocolатрибута класса.

• Новый django.test.SimpleTestCaseподкласс unittest.TestCase светлее django.test.TestCaseи рота. Это может быть полезно в тестах, которые не требуют обращения к базе данных. См. Иерархию классов модульного тестирования Django .

Требуется настройка SECRET_KEY ¶

Запуск Django с пустым или известным значением SECRET_KEYотключает многие средства защиты Django и может привести к уязвимостям удаленного выполнения кода. Ни один сайт Django не должен запускаться без файла SECRET_KEY.

В Django 1.4 запуск Django с пустым файлом SECRET_KEYвызовет расширение DeprecationWarning. В Django 1.5 это вызовет исключение, и Django откажется запускаться. Это немного ускорено по сравнению с обычным путем отказа от поддержки из-за серьезности последствий запуска Django без SECRET_KEY.

django.contrib.admin¶

Включенное приложение администрирования django.contrib.adminуже давно поставляется с набором статических файлов по умолчанию, таких как JavaScript, изображения и таблицы стилей. В Django 1.3 добавлено новое приложение contrib django.contrib.staticfiles для универсальной обработки таких файлов и определены соглашения для статических файлов, включенных в приложения.

Начиная с Django 1.4 статические файлы администратора также следуют этому соглашению, чтобы упростить развертывание файлов. В предыдущих версиях Django также было принято определять ADMIN_MEDIA_PREFIXпараметр, указывающий на URL-адрес, по которому статические файлы администратора находятся на веб-сервере. Этот параметр устарел и заменен более общим параметром STATIC_URL. Теперь Django ожидает найти статические файлы администратора по URL-адресу <STATIC_URL>/admin/.

Если вы ранее использовали URL - путь ADMIN_MEDIA_PREFIX(например /media/) , просто убедитесь , STATIC_URLи STATIC_ROOT настроены , и ваш веб - сервер правильно выполняет эти файлы. Сервер разработки продолжает обслуживать файлы администратора, как и раньше. Прочтите инструкции по статическим файлам для получения более подробной информации.

Если ваш ADMIN_MEDIA_PREFIXустановлен на конкретный домен (например http://media.example.com/admin/), не забудьте также установить STATIC_URLправильный URL-адрес - например http://media.example.com/,.

Поддерживаемые браузеры для админа ¶

У Django не было четкой политики, согласно которой браузеры поддерживаются приложением администратора. Наша новая политика формализует существующие практики: браузеры YUI A-grade должны предоставлять полнофункциональные возможности администрирования, за заметным исключением Internet Explorer 6, который больше не поддерживается.

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

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

Удалены иконки админки ¶

В рамках усилий по повышению производительности и удобства использования интерфейса сортировки списков изменений администратора horizontalи verticalвиджетов «фильтров» некоторые файлы значков были удалены и сгруппированы в два файла спрайтов.

В частности: selector-add.gif, selector-addall.gif, selector-remove.gif, selector-removeall.gif, selector_stacked-add.gifи selector_stacked-remove.gifбыли объединены в selector-icons.gif; и arrow-up.gifи arrow-down.gifбыли объединены в sorting-icons.gif.

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

Имена классов CSS в формах администратора ¶

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

Совместимость со старыми подписанными данными ¶

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

Итак, если вы обновитесь до Django 1.4 напрямую с 1.2 или более ранней версии, вы можете потерять / сделать недействительными определенные части данных, которые были криптографически подписаны с использованием старого метода. Чтобы избежать этого, сначала используйте Django 1.3 в течение определенного периода времени, чтобы подписанные данные истекли естественным образом. Затронутые части подробно описаны ниже: 1) последствия игнорирования этого совета и 2) количество времени, необходимое для запуска Django 1.3, чтобы данные устарели или стали неактуальными.

• contrib.sessions проверка целостности данных
  • Последствия: пользователь выйдет из системы, и данные сеанса будут потеряны.
  • Период времени: определяется пользователем SESSION_COOKIE_AGE.
• contrib.auth хеш сброса пароля
  • Последствия: ссылки для сброса пароля, использованные до обновления, не работают.
  • Период времени: определяется пользователем PASSWORD_RESET_TIMEOUT_DAYS.

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

• contrib.comments сформировать хэш безопасности
  • Последствия: пользователь увидит ошибку проверки «Ошибка хэша безопасности».
  • Период времени: ожидаемое количество времени, которое пользователи потратят на заполнение форм комментариев.
• FormWizard хэш безопасности
  • Последствия: пользователь увидит ошибку об истечении срока действия формы и будет отправлен обратно на первую страницу мастера, при этом введенные данные будут утеряны.
  • Период времени: ожидаемое количество времени, которое пользователи потратят на заполнение затронутых форм.
• CSRF проверка
  • Примечание. На самом деле это резервный вариант Django 1.1, а не Django 1.2, и он применяется только при обновлении с 1.1.
  • Последствия: пользователь увидит ошибку 403 в любой форме POST, защищенной CSRF.
  • Период времени: ожидаемое количество времени, которое пользователь потратит на заполнение таких форм.
• contrib.auth последовательность обновления хэша пароля пользователя
  • Последствия: пароль каждого пользователя будет обновлен до более надежного хэша пароля, когда он будет записан в базу данных в версии 1.4. Это означает, что если вы обновитесь до 1.4, а затем вам потребуется перейти на более раннюю версию 1.3, версия 1.3 не сможет читать обновленные пароли.
  • Способ устранения: PASSWORD_HASHERSпри первоначальном обновлении до версии 1.4 установите использование исходного хеширования пароля. После того, как вы подтвердите, что ваше приложение работает с Django 1.4 и вам не придется откатываться до версии 1.3, включите новые хэши паролей.

django.contrib.flatpages¶

Начиная с версии 1.4, FlatpageFallbackMiddlewareдобавляется косая черта в конце и выполняется перенаправление только в том случае, если полученный URL ссылается на существующую плоскую страницу. Например, запрос /notaflatpageoravalidurlв предыдущей версии будет перенаправлять на /notaflatpageoravalidurl/, что впоследствии вызовет 404. Запрос /notaflatpageoravalidurlсейчас немедленно вызовет 404.

Кроме того, перенаправления, возвращаемые плоскими страницами, теперь являются постоянными (с кодом состояния 301), чтобы соответствовать поведению CommonMiddleware.

Сериализация datetimeи ¶time

Вследствие поддержки часовых поясов и в соответствии со спецификацией ECMA-262 мы внесли изменения в сериализатор JSON:

• Он включает часовой пояс для известных объектов datetime. Это вызывает исключение для известных объектов времени.
• Он включает миллисекунды для объектов datetime и time. По-прежнему есть некоторая потеря точности, потому что Python хранит микросекунды (6 цифр), а JSON поддерживает только миллисекунды (3 цифры). Однако это лучше, чем полностью отбрасывать микросекунды.

Мы изменили сериализатор XML для использования формата даты и времени ISO8601. Буква Tиспользуется для отделения части даты от части времени, а не пробела. Информация о часовом поясе включена в [+-]HH:MMформат.

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

supports_timezoneизменен на Falseдля SQLite ¶

Функция базы данных supports_timezoneраньше была Trueдля SQLite. Действительно, если вы сохранили известный объект datetime, SQLite сохранил строку, которая включала смещение UTC. Однако это смещение было проигнорировано при загрузке значения обратно из базы данных, что могло повредить данные.

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

MySQLdb-специфические исключения ¶

Исторически сложилось так, что серверная часть MySQL MySQLdb.OperationalError срабатывала, когда запрос вызывал исключение. Мы исправили эту ошибку и теперь делаем рейз django.db.DatabaseError. Если вы тестировали MySQLdb.OperationalError, вам нужно обновить свои except предложения.

Расположение потока подключения к базе данных ¶

DatabaseWrapperобъекты (т. е. объекты соединения, на которые ссылается django.db.connectionи django.db.connections["some_alias"]) раньше были локальными для потока. Теперь они являются глобальными объектами, которые потенциально могут использоваться несколькими потоками. Хотя отдельные объекты соединения теперь являются глобальными, django.db.connectionsсловарь, ссылающийся на эти объекты, по-прежнему является локальным для потока. Поэтому, если вы просто используете ORM или, DatabaseWrapper.cursor()то поведение останется таким же, как и раньше. Обратите внимание, однако, что django.db.connectionэто больше не ссылается напрямую на DatabaseWrapperобъект по умолчанию и теперь является прокси для доступа к атрибутам этого объекта. Если вам нужен доступ к фактическому DatabaseWrapper объекту, используйте django.db.connections[DEFAULT_DB_ALIAS]вместо него.

В рамках этого изменения все базовые соединения SQLite теперь включены для потенциального совместного использования потоков (путем передачи check_same_thread=Falseатрибута в pysqlite). DatabaseWrapperоднако сохраняет предыдущее поведение, отключая совместное использование потоков по умолчанию, поэтому это не влияет на какой-либо существующий код, который полностью полагается на ORM или на DatabaseWrapper.cursor().

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

COMMENTS_BANNED_USERS_GROUPнастройка ¶

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

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

from django.conf import settings
from django.contrib.comments.managers import CommentManager

class BanningCommentManager(CommentManager):
    def get_query_set(self):
        qs = super().get_query_set()
        if getattr(settings, 'COMMENTS_BANNED_USERS_GROUP', None):
            where = ['user_id NOT IN (SELECT user_id FROM auth_user_groups WHERE group_id = %s)']
            params = [settings.COMMENTS_BANNED_USERS_GROUP]
            qs = qs.extra(where=where, params=params)
        return qs

Сохраните этот менеджер моделей в своем приложении для пользовательских комментариев (например, в my_comments_app/managers.py) и добавьте его в свою модель приложения для пользовательских комментариев:

from django.db import models
from django.contrib.comments.models import Comment

from my_comments_app.managers import BanningCommentManager

class CommentWithTitle(Comment):
    title = models.CharField(max_length=300)

    objects = BanningCommentManager()

IGNORABLE_404_STARTSи IGNORABLE_404_ENDSнастройки ¶

До Django 1.3 можно было исключить некоторые URL-адреса из отчетов об ошибках 404 Django, добавляя префиксы к IGNORABLE_404_STARTSи суффиксы к IGNORABLE_404_ENDS.

В Django 1.4 эти две настройки заменены на IGNORABLE_404_URLS, который представляет собой список скомпилированных регулярных выражений. Django не отправляет электронное письмо с ошибками 404 для URL-адресов, соответствующих любому из них.

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

IGNORABLE_404_STARTS = ('/cgi-bin/', '/_vti_bin', '/_vti_inf')
IGNORABLE_404_ENDS = ('mail.pl', 'mailform.pl', 'mail.cgi', 'mailform.cgi',
                      'favicon.ico', '.php')

Django не должен решать, есть ли на вашем веб-сайте унаследованный /cgi-bin/ раздел или favicon.ico. Как следствие, все значения по умолчанию IGNORABLE_404_URLS, IGNORABLE_404_STARTSи IGNORABLE_404_ENDSтеперь пусты.

Если вы настроили IGNORABLE_404_STARTSили IGNORABLE_404_ENDS, или если хотите сохранить старое значение по умолчанию, вам следует добавить следующие строки в свой файл настроек:

import re
IGNORABLE_404_URLS = (
    # for each <prefix> in IGNORABLE_404_STARTS
    re.compile(r'^<prefix>'),
    # for each <suffix> in IGNORABLE_404_ENDS
    re.compile(r'<suffix>$'),
)

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

Защита CSRF расширена до PUT и DELETE ¶

Ранее защита Django от CSRF обеспечивала защиту только от запросов POST. Поскольку использование методов PUT и DELETE в приложениях AJAX становится все более распространенным, теперь мы защищаем все методы, не определенные как безопасныеRFC 2616 - то есть мы исключаем GET, HEAD, OPTIONS и TRACE, и мы обеспечиваем защиту всего остального.

Если вы используете методы PUT или DELETE в приложениях AJAX, ознакомьтесь с инструкциями по использованию AJAX и CSRF .

Просмотр сброса пароля теперь поддерживает subject_template_name¶

password_resetВид в django.contrib.authнастоящее принимает subject_template_nameпараметр, который передается с паролем сохранить форму в качестве ключевого слова аргумента. Если вы используете это представление с настраиваемой формой сброса пароля, вам необходимо убедиться, что save()метод вашей формы принимает этот аргумент ключевого слова.

django.core.template_loaders¶

Это был псевдоним django.template.loaderс 2005 года, и мы удалили его без предупреждения из-за продолжительности устаревания. Если ваш код все еще ссылается на это, используйте django.template.loaderвместо этого.

django.db.models.fields.URLField.verify_exists¶

Эта функция была удалена из-за неразрешимых проблем с производительностью и безопасностью. Любое существующее использование verify_existsдолжно быть удалено.

django.core.files.storage.Storage.open¶

openМетод базового класса Storage используется принять неясный параметр , mixinкоторый позволял динамически изменять базовые классы возвращенного объекта файла. Это было удалено. В редких случаях, когда вы полагались на mixinпараметр, вы можете легко добиться того же, переопределив open метод, например:

from django.core.files import File
from django.core.files.storage import FileSystemStorage

class Spam(File):
    """
    Spam, spam, spam, spam and spam.
    """
    def ham(self):
        return 'eggs'

class SpamStorage(FileSystemStorage):
    """
    A custom file storage backend.
    """
    def open(self, name, mode='rb'):
        return Spam(open(self.path(name), mode))

Десериализатор YAML теперь использует yaml.safe_load¶

yaml.loadможет создать любой объект Python, который может вызвать выполнение произвольного кода, если вы обрабатываете документ YAML, полученный из ненадежного источника. Эта функция не требуется для десериализатора Django YAML, основное назначение которого - загрузка фикстур, состоящих из простых объектов. Несмотря на то, что фикстуры являются надежными данными, десериализатор YAML теперь использует их yaml.safe_load для дополнительной безопасности.

Сессионные куки теперь имеют httponlyфлаг по умолчанию ¶

Сеансовые куки-файлы теперь включают httponlyатрибут по умолчанию, чтобы уменьшить влияние потенциальных XSS-атак. В результате этого изменения данные cookie сеанса, включая sessionid, больше не доступны из JavaScript во многих браузерах. Для строгой обратной совместимости используйте в файле настроек.SESSION_COOKIE_HTTPONLY = False

Не urlizeфильтр больше не ускользает каждый URL ¶

Когда URL-адрес содержит %xxпоследовательность, состоящую xxиз двух шестнадцатеричных цифр, urlizeтеперь предполагается, что URL-адрес уже экранирован, и не применяет экранирование URL-адреса снова. Это неверно для URL-адресов, чья форма без кавычек содержит %xxпоследовательность, но такие URL-адреса очень маловероятны, потому что они также сбивают с толку браузеры.

assertTemplateUsedи assertTemplateNotUsedкак менеджер контекста ¶

Теперь можно проверить, использовался ли шаблон в блоке кода, с помощью assertTemplateUsed()и assertTemplateNotUsed(). И их можно использовать как диспетчер контекста:

with self.assertTemplateUsed('index.html'):
    render_to_string('index.html')
with self.assertTemplateNotUsed('base.html'):
    render_to_string('index.html')

См. Дополнительную информацию в документации по утверждениям .

Подключения к базе данных после запуска набора тестов ¶

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

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

Выход ¶manage.py help

manage.py helpтеперь группирует доступные команды по приложениям. Если вы зависели от вывода этой команды - если вы, например, проанализировали его, - вам необходимо обновить свой код. Чтобы получить список всех доступных команд управления в сценарии, используйте вместо этого.manage.py help --commands

extendsтег шаблона ¶

Раньше extendsтег использовал ошибочный метод анализа аргументов, что могло привести к ошибочному рассмотрению аргумента как строкового литерала, когда это не так. Теперь он использует parser.compile_filter, как и другие теги.

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

Загрузка некоторых неполных светильников больше не работает ¶

До версии 1.4 значение по умолчанию было вставлено для объектов фикстуры, у которых отсутствовала конкретная дата или значение datetime, когда для поля были установлены auto_now или auto_now_add. Это было то, что не должно было работать, и в версии 1.4 загрузка таких неполных приспособлений не удастся. Поскольку фикстуры являются необработанным импортом, они должны явно указывать все значения полей, независимо от параметров поля в модели.

Многопоточность сервера разработки ¶

Сервер разработки теперь по умолчанию является многопоточным. Используйте параметр, чтобы отключить использование потоковой передачи на сервере разработки:runserver --nothreading

django-admin.py runserver --nothreading

Атрибуты отключены в уценке при установке безопасного режима ¶

До Django 1.4 атрибуты включались в любой вывод уценки независимо от настройки безопасного режима фильтра. В версии> 2.1 библиотеки Python-Markdown была добавлена ​​опция enable_attributes. Когда безопасный аргумент передается уценки фильтра, как safe_mode=Trueи enable_attributes=Falseпараметры установлены. Если используется версия библиотеки Python-Markdown ниже 2.1, выдается предупреждение о том, что вывод небезопасен.

FormMixin get_initial возвращает словарь для конкретного экземпляра ¶

В Django 1.3 get_initialметод django.views.generic.edit.FormMixinкласса возвращал initialсловарь класса . Это было исправлено, чтобы возвращать копию этого словаря, поэтому экземпляры формы могут изменять свои начальные данные, не вмешиваясь в переменную класса.

Старые стили вызова cache_pageдекоратора ¶

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

Поддержка версий PostgreSQL старше 8.2 ¶

Django 1.3 отказался от поддержки версий PostgreSQL старше 8.0, и мы предложили использовать более свежую версию из-за повышения производительности и, что более важно, близился конец периодов поддержки исходных версий для 8.0 и 8.1 (ноябрь 2010 г.).

Django 1.4 развивает эту политику и устанавливает минимальную официально поддерживаемую версию PostgreSQL 8.2.

Исключения запросов теперь всегда регистрируются ¶

Когда мы добавили поддержку ведения журнала в Django в версии 1.3, поддержка электронной почты при ошибках администратора была перенесена в файл django.utils.log.AdminEmailHandler, прикрепленный к 'django.request'регистратору. Чтобы поддерживать установленное поведение сообщений об ошибках, 'django.request'регистратор вызывался только тогда, когда DEBUGбыл False.

Чтобы повысить гибкость ведения журнала ошибок для запросов, 'django.request'регистратор теперь вызывается независимо от значения DEBUG, а файл настроек по умолчанию для новых проектов теперь включает отдельный фильтр, прикрепленный к, django.utils.log.AdminEmailHandlerчтобы предотвратить электронные сообщения об ошибках администратора в DEBUGрежиме:

'filters': {
     'require_debug_false': {
         '()': 'django.utils.log.RequireDebugFalse'
     }
 },
 'handlers': {
     'mail_admins': {
         'level': 'ERROR',
         'filters': ['require_debug_false'],
         'class': 'django.utils.log.AdminEmailHandler'
     }
 },

Если ваш проект был создан до этого изменения, ваши LOGGING настройки не будут включать этот новый фильтр. Чтобы поддерживать обратную совместимость, Django обнаружит, что ваша 'mail_admins'конфигурация обработчика не содержит 'filters'раздела, и автоматически добавит этот фильтр для вас и выдаст предупреждение об отложении поддержки. Это станет предупреждением об устаревании в Django 1.5, а в Django 1.6 прокладка обратной совместимости будет полностью удалена.

Наличие любого 'filters'ключа в 'mail_admins'обработчике отключит эту прокладку обратной совместимости и предупреждение об устаревании.

django.conf.urls.defaults¶

До Django 1.3, include(), patterns(), и url()функции, а также handler404и handler500 были расположены в django.conf.urls.defaultsмодуле.

В Django 1.4 они живут в django.conf.urls.

django.contrib.databrowse¶

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

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

django.core.management.setup_environ¶

Эта функция временно изменена sys.path, чтобы сделать родительский каталог «проект» доступным для импорта в старом плоском startproject макете. Эта функция теперь устарела, так как обходные пути ее пути больше не нужны с новым manage.pyмакетом проекта по умолчанию.

Эта функция никогда не была документирована и не была частью общедоступного API, но ее широко рекомендовали для использования при настройке «среды Django» для пользовательского скрипта. Эти варианты использования следует заменить установкойDJANGO_SETTINGS_MODULE переменная окружения или использование django.conf.settings.configure().

django.core.management.execute_manager¶

Эта функция ранее использовалась manage.pyдля выполнения команды управления. Он идентичен django.core.management.execute_from_command_line, за исключением того, что он сначала вызывает setup_environ, что теперь не рекомендуется. Таким образом, execute_manager также устарел; execute_from_command_lineможно использовать вместо этого. Ни одна из этих функций не задокументирована как часть общедоступного API, но необходим путь устаревания из-за использования в существующих manage.pyфайлах.

is_safeи needs_autoescapeатрибуты шаблонных фильтров ¶

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

@register.filter
def noop(value):
    return value
noop.is_safe = True

Однако этот прием вызвал некоторые проблемы, особенно в сочетании с декораторами @stringfilter. Теперь флаги являются ключевыми аргументами @register.filter:

@register.filter(is_safe=True)
def noop(value):
    return value

См. Фильтры и автоматическое экранирование для получения дополнительной информации.

Wildcard расширение имен приложений в INSTALLED_APPS¶

До Django 1.3 INSTALLED_APPSдопускались подстановочные знаки в именах приложений, например django.contrib.*. Расширение было выполнено реализацией файловой системы . К сожалению, надежно это сделать нельзя.from <package> import *

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

HttpRequest.raw_post_dataпереименован в HttpRequest.body¶

Название этого атрибута было сбивающим с толку HttpRequest.raw_post_data, но на самом деле он представлял собой тело HTTP-запроса. Он был переименован в HttpRequest.bodyи больше HttpRequest.raw_post_dataне поддерживается.

django.contrib.sitemapsисправление ошибки с потенциальными последствиями для производительности ¶

В предыдущих версиях Paginatorобъекты, используемые в классах карты сайта, кэшировались, что могло привести к устареванию карт сайта. Мы удалили кеширование, поэтому каждый запрос к карте сайта теперь создает новый объект Paginator и вызывает items()метод Sitemapподкласса. В зависимости от того, что делает ваш items()метод, это может отрицательно сказаться на производительности. Чтобы уменьшить влияние на производительность, рассмотрите возможность использования инфраструктуры кэширования в своем Sitemapподклассе.

Версии Python-Markdown до 2.1 ¶

Версии Python-Markdown до 2.1 не поддерживают возможность отключения атрибутов. В целях безопасности более ранние версии этой библиотеки не будут поддерживаться приложением разметки contrib в версии 1.5 в соответствии с ускоренным графиком прекращения поддержки.